Am 31.05.2018 um 07:55 schrieb Robert Elz <kre@munnari.OZ.AU>:
Date: Wed, 30 May 2018 23:29:15 -0400 From: Aldrin Martoq Ahumada <aldrin.martoq@gmail.com> Message-ID: <D8D64C7C-CBF2-4F58-8146-1D4D3E3A322A@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-timest... 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