Deciding on Interface

[quinnj]

As people actually need this package now, I figure it's time to figure out a good interface. I'll list a few options off the top of my head, mainly ideas that have come up in various discussions (when we merged Dates.jl into Base, an old issue or two in the Dates.jl repo, etc.).

• Full on ZonedDateTime type: it would basically wrap a DateTime and probably some kind of TimeZone type that held the offset/DST/abbreviation information; through show the DateTime (which would be UTC) and the TimeZone info would be combined to show the offsetted datetime.
• At one point, it occurred to me that dealing with timezones is almost purely an IO issue. Sometimes you get timezoned datetimes that you need to read in and convert to UTC. Other times you have UTC datetimes and you need to output the datetime according to a certain timezone. With this interface, there is no "aggregate type", just IO functions around timezones (parsing timezoned datetimes, converting DateTimes between timezones, and an output format function for displaying DateTime according to a timezone). I personally feel like, while different from most other implementations, this is a very good way to think/work with timezones. It forces the user to immediately get their data into UTC (since that's the only "type"), so data is stored/processed/calculated all in UTC which has very clear, sensible calculation rules. It still allows, however, one to work with timezones by parsing and outputting.

[iamed2]

I'm strongly in favour of UTC under the hood!

One feature that does need to be considered is ZonedDateTime repeating. A user may wish to get 6am every day in a DST-aware time zone, which does not result in a constant difference between ZonedDateTimes when represented in UTC. I'm thinking this can be done with custom range types, but we'll have to make sure addition is efficient.

I have time to devote to this so let me know how I can help!

[ivarne]

One thing that is missing is leap seconds. As far as I remember standard DateTime, doesn`t take leap seconds into account, but UTC defines and uses them.

As @iamed2 mentions, correct time deltas (in days) in face of DST and other political decicions would be a really great in addidion to be able to convert a psudo UTC timestamp to a local time for presentation.

[iamed2]

@ivarne The time representation chosen for Julia in the Dates module does not include leap seconds. http://docs.julialang.org/en/latest/manual/dates/#id2

[omus]

I've been working on the Julia TimeZone interface and have got most of the work done. I need to write up some documentation but here is a brief peak into how things are working:

julia> using TimeZones
julia> warsaw = TimeZone("Europe/Warsaw")
Europe/Warsaw

julia> ZonedDateTime(DateTime(2015,10,25), warsaw)
2015-10-25T00:00:00+02:00

julia> import Base.Dates: Hour, Day
julia> ZonedDateTime(DateTime(2015,10,25,2), warsaw)
ERROR: Local DateTime 2015-10-25T02:00:00 is ambiguious
 in ZonedDateTime at /Users/omus/.julia/v0.4/TimeZones/src/timezones/types.jl:133
 in ZonedDateTime at /Users/omus/.julia/v0.4/TimeZones/src/timezones/types.jl:121

julia> ZonedDateTime(DateTime(2015,10,25,2), warsaw, 1)  # First occurrence of hour 2
2015-10-25T02:00:00+02:00

julia> ZonedDateTime(DateTime(2015,10,25,2), warsaw, 2)  # Second occurrence of hour 2
2015-10-25T02:00:00+01:00

julia> ZonedDateTime(DateTime(2015,10,25), warsaw) + Day(1) # Calendrical arithmetic 
2015-10-26T00:00:00+01:00

julia> ZonedDateTime(DateTime(2015,10,25), warsaw) + Hour(24) # A 25 hour day
2015-10-25T23:00:00+01:00

Code can be found on the interface branch

[quinnj]

woot.

[quinnj]

hey @omus, do you want to do a PR? I'd rather just merge this is and we can play with the interface

[omus]

Will do @quinnj. I'll make the PR tomorrow.

[omus]

Closing as the #3 branch was accepted.

[quinnj]

+1