[tz] On solving the tzdata changes problem
andreas at heigl.org
Thu May 31 07:46:28 UTC 2018
> Am 31.05.2018 um 07:55 schrieb Robert Elz <kre at munnari.OZ.AU>:
> Date: Wed, 30 May 2018 23:29:15 -0400
> From: Aldrin Martoq Ahumada <aldrin.martoq at gmail.com>
> Message-ID: <D8D64C7C-CBF2-4F58-8146-1D4D3E3A322A at gmail.com>
> | The problem is that there is no historical data of tzdata:
> No, the problem is that the application model is broken. If the dentist
> appointment is at some local time in America/Santiago then it should
> be stored that way, not in UTC ("that way" can be either to simply
> represent the local time, or to store UTC along with the offset that
> applied when it was converted to UTC)
I'd suggest to *not* convert to UTC but to store local time: https://andreas.heigl.org/2016/12/22/why-not-to-convert-a-datetime-to-timestamp/
> - and in either case an indication
> that it is local time in America/Santiago which is being represented.
> Handling time is much more complex that most people think, as once
> one has learned to read a clock, it is generally simply assumed that
> there's no more to it, and time is now "understood". That's just wrong.
> Anything that deals with times needs an accompanying (explicit or
> implicit) timezone associated with it - something that defines in what
> specific zone the time is fixed. Sometimes that might be UTC, though
> it usually isn't. The dentist appointment time would be local time at the
> office (that's the way things are scheduled) and changing the offset
> between that local time and UTC would make no difference at all to the
> local time set for the appointment.
> Any application to deal with this needs to be able to handle that kind of
> issue, and do it properly.
> This doesn't mean that your tool for examing differences between one
> tzdata version and another isn't useful - it just isn't (or shouldn't be)
> useful for that kind of application.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tz