<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br><div>Am 31.05.2018 um 07:55 schrieb Robert Elz <<a href="mailto:kre@munnari.OZ.AU">kre@munnari.OZ.AU</a>>:<br><br></div><blockquote type="cite"><div><span> Date: Wed, 30 May 2018 23:29:15 -0400</span><br><span> From: Aldrin Martoq Ahumada <<a href="mailto:aldrin.martoq@gmail.com">aldrin.martoq@gmail.com</a>></span><br><span> Message-ID: <<a href="mailto:D8D64C7C-CBF2-4F58-8146-1D4D3E3A322A@gmail.com">D8D64C7C-CBF2-4F58-8146-1D4D3E3A322A@gmail.com</a>></span><br><span></span><br><span> | The problem is that there is no historical data of tzdata: </span><br><span></span><br><span>No, the problem is that the application model is broken. If the dentist </span><br><span>appointment is at some local time in America/Santiago then it should</span><br><span>be stored that way, not in UTC ("that way" can be either to simply</span><br><span>represent the local time, or to store UTC along with the offset that</span><br><span>applied when it was converted to UTC)</span></div></blockquote><br><div><span style="background-color: rgba(255, 255, 255, 0);">I'd suggest to *not* convert to UTC but to store local time: <a href="https://andreas.heigl.org/2016/12/22/why-not-to-convert-a-datetime-to-timestamp/">https://andreas.heigl.org/2016/12/22/why-not-to-convert-a-datetime-to-timestamp/</a></span><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">Cheers</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><font style="background-color: rgba(255, 255, 255, 0);">Andreas</font></div></div><div><br></div><blockquote type="cite"><div><span> - and in either case an indication</span><br><span>that it is local time in America/Santiago which is being represented.</span><br><span></span><br><span>Handling time is much more complex that most people think, as once</span><br><span>one has learned to read a clock, it is generally simply assumed that</span><br><span>there's no more to it, and time is now "understood". That's just wrong.</span><br><span></span><br><span>Anything that deals with times needs an accompanying (explicit or</span><br><span>implicit) timezone associated with it - something that defines in what</span><br><span>specific zone the time is fixed. Sometimes that might be UTC, though</span><br><span>it usually isn't. The dentist appointment time would be local time at the</span><br><span>office (that's the way things are scheduled) and changing the offset</span><br><span>between that local time and UTC would make no difference at all to the</span><br><span>local time set for the appointment.</span><br><span></span><br><span>Any application to deal with this needs to be able to handle that kind of</span><br><span>issue, and do it properly.</span><br><span></span><br><span>This doesn't mean that your tool for examing differences between one</span><br><span>tzdata version and another isn't useful - it just isn't (or shouldn't be)</span><br><span>useful for that kind of application.</span><br><span></span><br><span>kre</span><br><span></span><br></div></blockquote></body></html>