You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
chrono-tz contains the Olson TZ data (at least, AFAICT, it does on crates.io, although it's not in git). No doubt this is good for Windows where the OS does not provide sensible timezone data.
But on Unix, the OS provides the Olson TZ database directly, generally in /usr/share/zoneinfo. OS updates update it. On Unix it is not right that Rust programs should end up with the timezone data embedded into the program, because if governments change the clocks (which they have been known to do at very short notice) this should be handled by an OS update, not by having to give everyone rebuilt Rust binaries.
So it seems to me that on Unix, chrono-tz should (by default at least) only use data from the OS installed timezone database. Would you be amenable to something like this? It seems to me that the default behaviour should be controlled by a feature flag.
I think implementing this needs an impl of TimeZone for &[parse_zoneinfo::ZoneInfo], or something along those lines.
The text was updated successfully, but these errors were encountered:
Hi.
chrono-tz contains the Olson TZ data (at least, AFAICT, it does on crates.io, although it's not in git). No doubt this is good for Windows where the OS does not provide sensible timezone data.
But on Unix, the OS provides the Olson TZ database directly, generally in /usr/share/zoneinfo. OS updates update it. On Unix it is not right that Rust programs should end up with the timezone data embedded into the program, because if governments change the clocks (which they have been known to do at very short notice) this should be handled by an OS update, not by having to give everyone rebuilt Rust binaries.
So it seems to me that on Unix, chrono-tz should (by default at least) only use data from the OS installed timezone database. Would you be amenable to something like this? It seems to me that the default behaviour should be controlled by a feature flag.
I think implementing this needs an impl of
TimeZone
for&[parse_zoneinfo::ZoneInfo]
, or something along those lines.The text was updated successfully, but these errors were encountered: