<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 31, 2018, at 3:46 AM, Andreas Heigl <<a href="mailto:andreas@heigl.org" class="">andreas@heigl.org</a>> wrote:</div><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><br class=""><div class="">Am 31.05.2018 um 07:55 schrieb Robert Elz <<a href="mailto:kre@munnari.OZ.AU" class="">kre@munnari.OZ.AU</a>>:<br class=""></div><blockquote type="cite" class=""><div class=""><span class=""> Date: Wed, 30 May 2018 23:29:15 -0400</span><br class=""><span class=""> From: Aldrin Martoq Ahumada <<a href="mailto:aldrin.martoq@gmail.com" class="">aldrin.martoq@gmail.com</a>></span><br class=""><span class=""> Message-ID: <<a href="mailto:D8D64C7C-CBF2-4F58-8146-1D4D3E3A322A@gmail.com" class="">D8D64C7C-CBF2-4F58-8146-1D4D3E3A322A@gmail.com</a>></span><br class=""><span class=""></span><br class=""><span class=""> | The problem is that there is no historical data of tzdata: </span><br class=""><span class=""></span><br class=""><span class="">No, the problem is that the application model is broken. If the dentist </span><br class=""><span class="">appointment is at some local time in America/Santiago then it should</span><br class=""><span class="">be stored that way, not in UTC ("that way" can be either to simply</span><br class=""><span class="">represent the local time, or to store UTC along with the offset that</span><br class=""><span class="">applied when it was converted to UTC)</span></div></blockquote><br class=""><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">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/" class="">https://andreas.heigl.org/2016/12/22/why-not-to-convert-a-datetime-to-timestamp/</a></span></div></div></div></blockquote><div><br class=""></div>Hi Robert and Andreas, thank both of you for your comments. I think I failed in the humility test here, I assumed we all know in this list time is really complicated and I’m sorry because I didn’t mean that my tool is bullet proof.</div><div><br class=""></div><div>There are many ways to keep date in systems, like using always local time, storing dates with UTC offset, or with a timezone like America/Santiago, or storing them with some form of location where you are working, like a city. All of them aren’t wrong or right by themselves, they just depend on their context if they are enough or not. And if it works for you, that’s great!</div><div><br class=""></div><div>My proposal is not perfect, and there is not a single solution that solves all the problems. Even if you implement what I’m proposing in your systems, there will be dates that can easily be migrated, some that must not be migrated, and some that you may end asking the user for confirmation. It’s really complicated.</div><div><br class=""></div><div>In the case of a new timezone created for my country, most of the systems I know didn’t do anything to solve the issue, and just let the users suffer the consequences. I think that we could and should do better about this.</div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div>First, we need to increase awareness about how complicated this can be. just like you have done, I updated my old 2011 post here: <a href="https://medium.com/servicios-a0/about-time-and-computers-530dd3937582" class="">https://medium.com/servicios-a0/about-time-and-computers-530dd3937582</a>. And we have to do it constantly.</div><div><br class=""></div><div>Second, we have to make clear that there is no single approach that fits all systems. I, personally, think that we live in a global world, so we should try to make our systems somehow resilient to this inevitable changes. I know it because my country has randomly changed the DST this last 10 years. If your country is a decent one, may you have to deal with other countries that are not. I also think that normal people should be aware of the issues, not try to hide it. Make them choose their timezone explicitly if they are app is global. But again, it depends.</div><div><div><br class=""></div><div>And third, we must improve our software to handle this. Having a tool that can help you update a timezone could be one of this things. I think the upgrade process is actually too complicated to most software, many need a restart to take the changes, it would be awesome that system take new definitions without that. Maybe we could create an authoritative server like NTP, but for timezones.</div><div><br class=""></div><div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><span class="">- and in either case an indication</span><br class=""><span class="">that it is local time in America/Santiago which is being represented.</span><br class=""><span class=""></span><br class=""><span class="">Handling time is much more complex that most people think, as once</span><br class=""><span class="">one has learned to read a clock, it is generally simply assumed that</span><br class=""><span class="">there's no more to it, and time is now "understood". That's just wrong.</span><br class=""><span class=""></span><br class=""><span class="">Anything that deals with times needs an accompanying (explicit or</span><br class=""><span class="">implicit) timezone associated with it - something that defines in what</span><br class=""><span class="">specific zone the time is fixed. Sometimes that might be UTC, though</span><br class=""><span class="">it usually isn't. The dentist appointment time would be local time at the</span><br class=""><span class="">office (that's the way things are scheduled) and changing the offset</span><br class=""><span class="">between that local time and UTC would make no difference at all to the</span><br class=""><span class="">local time set for the appointment.</span><br class=""><span class=""></span><br class=""><span class="">Any application to deal with this needs to be able to handle that kind of</span><br class=""><span class="">issue, and do it properly.</span><br class=""><span class=""></span><br class=""><span class="">This doesn't mean that your tool for examing differences between one</span><br class=""><span class="">tzdata version and another isn't useful - it just isn't (or shouldn't be)</span><br class=""><span class="">useful for that kind of application.</span><br class=""><span class=""></span><br class=""><span class="">kre</span><br class=""><span class=""></span><br class=""></div></blockquote></div><div><br class=""></div><div>— </div><div>Aldrin.</div></div><br class=""></body></html>