# MySQL Date conversion failure
**URL:** https://discourse.julialang.org/t/mysql-date-conversion-failure/37644
**Category:** New to Julia
**Tags:** question
**Created:** [April 15, 2020, 2:10pm UTC](https://discourse.julialang.org/t/mysql-date-conversion-failure/37644 "2020-04-15T14:10:33Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@compleat](https://discourse.julialang.org/u/compleat)
#### Post date: [April 15, 2020, 2:10pm UTC](https://discourse.julialang.org/t/mysql-date-conversion-failure/37644/1 "2020-04-15T14:10:34Z")
I have managed to get MySQL.jl working, and it seems a very handy utility.
[I would be grateful for any up-to-date documentation on it - I had to figure it out from trial and error]
I managed to get MySQL.connect working and to get MySQL.query working for most of my needs.
However, there is one issue I can’t seem to overcome, which is that queries involving dates or times seem to fail over a conversion issue:
ERROR: MethodError: Cannot `convert` an object of type Type{DateTime} to an object of type Unsigned
I saw some reference to this online from some time ago, and a reference to setting something to zero in the connection string, but I could not seem to fit anything like that into MySQL.connect, or indeed to solve the problem using the Dates package.
It is probably something simple, but I just can’t seem to find it documented anywhere, and I would appreciate any help,
Thanks in advance
[Update: I had some success using ‘CAST’ conversion in my query, but any other suggestion avoiding conversion to ‘CHAR’ (string) would be better]
---
### Author:  [@dburch](https://discourse.julialang.org/u/dburch)
#### Post date: [April 15, 2020, 3:08pm UTC](https://discourse.julialang.org/t/mysql-date-conversion-failure/37644/2 "2020-04-15T15:08:04Z")
Do you have the full error message? Do you know what line of code is the issue?
---
### Author:  [@compleat](https://discourse.julialang.org/u/compleat)
#### Post date: [April 15, 2020, 3:09pm UTC](https://discourse.julialang.org/t/mysql-date-conversion-failure/37644/3 "2020-04-15T15:09:28Z")
Just a minute…
Closest candidates are:
convert(::Type{T\<:Number}, ::T\<:Number) where T\<:Number at number.jl:6
convert(::Type{T\<:Number}, ::Number) where T\<:Number at number.jl:7
convert(::Type{T\<:Integer}, ::Ptr) where T\<:Integer at pointer.jl:23
Stacktrace:
[1] unsigned(::Type) at ./int.jl:161
[2] julia\_type(::UInt32, ::Bool, ::Bool) at /home/davide/.julia/packages/MySQL/R2gKS/src/types.jl:62
[3] #3 at ./none:0 [inlined]
[4] iterate(::Base.Generator{Array{MySQL.API.MYSQL\_FIELD,1},getfield(MySQL, Symbol(“##3#5”))}, ::Int64) at ./generator.jl:47
[5] append\_any(::Any, ::Vararg{Any,N} where N) at ./essentials.jl:728
[6] #Query#1(::Bool, ::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}, ::Type{MySQL.Query}, ::MySQL.Connection, ::String) at /home/davide/.julia/packages/MySQL/R2gKS/src/types.jl:94
[7] MySQL.Query(::MySQL.Connection, ::String) at /home/davide/.julia/packages/MySQL/R2gKS/src/types.jl:79
[8] top-level scope at REPL[49]:1
Thanks for any help [stepping away for an hour]
Back now and will keep an eye. You should be able to recreate
the error by just trying a select query on a Date field in a db table.
---
### Author:  [@dburch](https://discourse.julialang.org/u/dburch)
#### Post date: [April 15, 2020, 8:02pm UTC](https://discourse.julialang.org/t/mysql-date-conversion-failure/37644/4 "2020-04-15T20:02:18Z")
I’m not sure what could be the issue. I do not use MySQL.jl myself, although I was about to start using it. If no one else responds, then you could try submitting an issue here: [https://github.com/JuliaDatabases/MySQL.jl/issues](https://github.com/JuliaDatabases/MySQL.jl/issues)
This seems like it might be a bug.
---
### Author:  [@compleat](https://discourse.julialang.org/u/compleat)
#### Post date: [April 15, 2020, 11:08pm UTC](https://discourse.julialang.org/t/mysql-date-conversion-failure/37644/5 "2020-04-15T23:08:23Z")
Thanks, I do think so as the example I tried is very basic. However, if you use CAST to convert the dates in the SQL syntax within MySQL, then that seems a sensible workaround and no too much trouble.
Apart from this, I was surprised to see how easy MySQL.jl is to use and how handy it is! Well-done coders!