[tz] On solving the tzdata changes problem

Thu May 31 20:42:16 UTC 2018

> On May 31, 2018, at 3:46 AM, Andreas Heigl <andreas at heigl.org> wrote:
> 
> Am 31.05.2018 um 07:55 schrieb Robert Elz <kre at munnari.OZ.AU <mailto:kre at munnari.OZ.AU>>:
>>    Date:        Wed, 30 May 2018 23:29:15 -0400
>>    From:        Aldrin Martoq Ahumada <aldrin.martoq at gmail.com <mailto:aldrin.martoq at gmail.com>>
>>    Message-ID:  <D8D64C7C-CBF2-4F58-8146-1D4D3E3A322A at gmail.com <mailto: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/ <https://andreas.heigl.org/2016/12/22/why-not-to-convert-a-datetime-to-timestamp/>
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.

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!

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.

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.

First, we need to increase awareness about how complicated this can be. just like you have done, I updated my old 2011 post here: https://medium.com/servicios-a0/about-time-and-computers-530dd3937582 <https://medium.com/servicios-a0/about-time-and-computers-530dd3937582>. And we have to do it constantly.

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.

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.

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

— 
Aldrin.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20180531/f350226b/attachment.html>