[tz] On solving the tzdata changes problem

[Andreas Heigl]

> 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/

Cheers

Andreas

> - 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.
> 
> kre
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20180531/840db7f8/attachment-0001.html>