[tz] On solving the tzdata changes problem

[Lester Caine]

On 31/05/18 06:55, Robert Elz wrote:
> 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.

The application model has never ben defined, but the starting point IS 
deciding on one's requirements. If you never need to worry about 
anything other than local time AND you have no DST changes to that time, 
then you can quite happily work with a clock which is shifted to UTC and 
ignore all this TZ stuff. Introducing DST requires a little more care if 
one is required to log when events take place since you have an overlap 
of time for a period each year. Usually an hour, but not exclusively. 
But you need to be able to identify cleanly the events before and after 
the transition, and using one or other time as a base time and flagging 
the DST offset ensures this is consistent. Normalising to UTC may have 
other advantages but is not essential.

Once one moves to a system which has clients world wide, logging in and 
out at all times of the day and night, this logging NEEDS a stable base 
which UTC provides. Many systems currently use 'server time' but 
managing changes in TWO lots of DST transitions does nothing for 
consistency especially where one is not entirely sure bother rule-sets 
are from the same version of data. Running everything UTC also prevents 
problems where distributed services on other servers are in different 
timezones as well. A server time clock should simply be UTC ...

Once you have a stable clock, then one can manage the time which is 
displayed based on the relevant rule set. Be that 'local time' of the 
events location or 'client time' of a remote users location. It is 
essential though that a change to an event due to new changes to the 
rule set can be picked up and normalised data corrected if required. The 
local time may not have changed, but the offset may have and it is that 
change which needs processing in the data side of things.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk