Curtis Vogt
Curtis Vogt
Added TZData separation issue (#359)
The main issue is that time zone abbreviations are used in many different time zones and in some cases refer to very different offsets. Take "CST" for example is used...
Failed on commit: https://github.com/JuliaTime/TimeZones.jl/pull/385/commits/46855088c42092cc8d68f0810059421a47b6e8a3
Saw this failure again in https://github.com/JuliaTime/TimeZones.jl/pull/384/commits/da91b27a01b1f396ecd4e1d70098ca2f6a16a983
I think this kind of change could be supported. The `utc_datetime` type needs to support date and time value with at least second precision. Currently `DateTime` is the only type...
I think this is worth experimenting with. Do you have a specific `AbstractTime` subtype you have in mind? Feel free to make a PR.
@JeffreySarnoff what may be a better approach is to make [`DateTime`](https://github.com/JuliaLang/julia/blob/9dc9c074c459cfbe6f20874398dabd3882fe15b2/base/dates/types.jl#L103) itself parametric. That way you can increase the precision of `DateTime` and get higher-precision `ZonedDateTime`s for free.
I'm not sure all subtypes of `AbstractDateTime` would require using a period internally. Any reason this cannot be tied to the `struct`?
Currently the `DateTime` in Base uses millisecond precision internally. Not all subtypes of `AbstractDateTime` may support a custom period: ```julia abstract type AbstractDateTime
Can you provide a link to your code? It would be nice to take a look to decide on the repo name.