3 ms·
> So you if you store local times as UTC, you might not get back the correct value when you convert back after a tzinfo update That shouldn't be a problem for
by dmm 6y ago
> So you if you store local times as UTC, you might not get back the correct value when you convert back after a tzinfo update
That shouldn't be a problem for datetimes in the past. tzdata contains not only the current offset but all historical ones as well.
It might be a problem for /future/ datetimes. If I say the meeting is at 1700 America/New_York and the local civil authority changes the offset in the meantime I probably don't want the meeting to move in local time.
- jmiserez 6y agoUnfortunately no, it can be a problem even for past dates. The new java.time and old java.util.TimeZone APIs use different offsets for dates < 1990, which resulted in a difference of 6 minutes and 32 seconds for my dates. I filed a bug (JDK-8214243) but basically it's a known issue and there's no fix.
- CodesInChaos 6y agoWhen migrating from .net's TimeZoneInfo (based on windows timezones) to NodaTime (based on tzdb) we ran into differences in the mid nineties for the German timezone.