chrono
chrono copied to clipboard
chronotope
Time zone handling
The docs/readme mention more advanced time zone handling planned for version 0.4. What will that look like. In particular, I'd like to be able to print time zone names so I can implement date for coreutils. Is there an opportunity to contribute here?
Wondering about this as well. chrono-tz implements IANA timezones like America/New_York but currently it just implements the entire database as part of the library (and massive match statements for converting to / from strings).
What are the plans for the future? Keep the functionality as a separate crate and improve that? Have IANA timezone support in chrono itself?
And if so, we can either embed the database like chrono-tz which is more portable (but then again, it's the entire database even for simple uses like date), or we can use the system's zoneinfo if available. On Linux, Mac, and most Unix-likes, it's at /usr/share/zoneinfo. On Android it's /system/usr/share/zoneinfo. On Windows it's in the registry with different names but here's a mapping for conversions.
I agree to @gnuish that we should leverage the existing platform-specific database as much as possible. Chrono-tz works today, but it is at best a backup database due to its inability to update itself in runtime (off-site tz distribution is hard, as pytz proves).
In the 0.2 era I had worked on the (binary) tzdata parser for that, and the changes to 0.3 TimeZone API are strictly made to avoid tons of nasty edge cases discovered while this work. So the most difficult part is already done, in principle the tzdata support is only bounded by the development resource (and mine turned out to be scarse sigh). For Windows support, one should look at the HLKM which is no different from tzdata except for the names (thank you for pointing out that CLDR has the mapping!).
Yeah I made the decision to use a git submodule to copy the raw tz data because getting platform-specific time zone data is hard. Maybe not so hard if you only have to support linux, but I didn't want that restriction. The tz files honestly update infrequently enough that I don't mind keeping them up-to-date, but there is a concern there with out-of-date tz files for rust software that has to be recompiled. I think there was an issue with turkey last year that got into the news (!!) for tz libs not being updated on phones.
The dynamic approach will take a bit of work and would probably require a different interface. Not sure if it is acceptable to look up the tz data from disk every time you create a new Datetime, so it would probably need some setup code to load the data first into some global structure... would like to avoid global state but maybe it's ok for this case - instead of passing a "TzData" struct into every function.
[...] because getting platform-specific time zone data is hard.
Maybe it's time to create the chrono-sys crate to explore the possibility :wink: