[tz] On solving the tzdata changes problem

Robert Elz kre at munnari.OZ.AU
Thu May 31 05:55:53 UTC 2018

    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) - 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.


More information about the tz mailing list