DateTime bug - Julia 0.6RC3

General Usage
1

There appears to be a bug(s) in the implementation of DateTime functions in Julia 0.6RC3 as shown below:

           _

_ _ ()_ | A fresh approach to technical computing
() | () () | Documentation: https://docs.julialang.org
_ _ | | __ _ | Type “?help” for help.
| | | | | | |/ ` | |
| | || | | | (| | | Version 0.6.0-rc3.0 (2017-06-07 11:53 UTC)
/ |_‘|||_’_| | Official http://julialang.org/ release
|__/ | x86_64-w64-mingw32

julia> dtnow=now()
2017-06-14T17:23:31.434

julia> dtnval=Dates.value(dtnow)
63633144211434

julia> dtnback=Dates.epochms2datetime(dtnval)
2016-06-14T17:23:31.434

julia> dtbase=DateTime(0)
0000-01-01T00:00:00

julia> dtbval=Dates.value(dtbase)
-31536000000

Clearly the epoch base was chosen as 0001-01-01T00:00:00 rather than 0000-01-01T00:00:00 as stated in the stdlib manual.

I would have raised an issue about this had I been able to figure out how to do so - being very new on github. Nevertheless I certainly would not have expected conversion and back conversion to have been off by a full year!

John Sutherland

2

Isn’t this just a mistake in the documentation then? It would be easy to submit a PR for that.

Also, please use code fences (```julia … ```) to format your code.

3

No it is not just a documentation problem. The code snippet

dt=now()
Dates.epochms2datetime(Dates.value(dt))

should return the original date/time rather than 1 year earlier.

This is a very simple usecase that should be added to the test suite.

Thanks for telling me about the code fences.

4

Maybe this solves the conundrum:

julia> dtbase=DateTime(Dates.UTM(0))
0000-12-31T00:00:00

julia> dtbval=Dates.value(dtbase)
0

Don’t ask me to explain the UTM. In general, I think there is a whole level of hell dedicated to time zones.

5

From the documentation, we see this:

‘’’
As Julia Date and DateTime values are represented according to the ISO 8601 standard, 0000-01-01T00:00:00 was chosen as base (or “rounding epoch”) from which to begin the count of days (and milliseconds) used in rounding calculations. (Note that this differs slightly from Julia’s internal representation of Date s using Rata Die notation; but since the ISO 8601 standard is most visible to the end user, 0000-01-01T00:00:00 was chosen as the rounding epoch instead of the 0000-12-31T00:00:00 used internally to minimize confusion.)
‘’’

Even if what I got actually is intended behaviour, I still feel there should be a function that back converts a datetime value to its original state. In my code, I’ve used the simple expedient of subtracting Dates.value(DateTime(0)) from the datetime value to be converted before calling the Dates.epochms2datetime function. However using different epoch and internal rounding values certainly does not minimize confusion!

6

On the assumption this is actually intended behaviour and not a bug, the documentation definitely needs to be updated to clarify the usage of function Dates.epochms2datetime.

My workaround is to subtract Dates.value(DateTime(0)) from my date time values before backconversion.

7

Realy, is not to cleary :

julia> T=Array{DateTime}(1)
1-element Array{DateTime,1}:
0000-12-31T00:00:00

julia> Dates.value.(T)
1-element Array{Int64,1}:
0
What to calculate time with this ?
Paul