[tz] Version in zoneinfo files?

Lester Caine lester at lsces.co.uk
Wed Oct 28 23:03:56 UTC 2015

Back on a computer with a real keyboard after floating around the Med
and being subjected to one hour time changes almost every night. Some
following the actual timezone and DST changes over the weekend, and
others arbitrary to avoid a 2 hour jump. So ships time did not match the
adjacent land time :) But at least the time was always quoted as an
offset ... from GMT ... standard sea time apparently.

>> On Oct 27, 2015, at 12:20 PM, lester at lsces.co.uk wrote:
>> The major problem all the time is identifying just what rules were applied when processing historic data, which may actually only be a current meeting diary. One can not assume that the current rule set actually correctly translates the current data if one set predates a later change. 
> I'm not sure I understood correctly what you intended.  Are you talking about this case:  I make a calendar entry for 9 am local time next year.  The calendar system translates that to UTC and stores that time in its database.  A few months later, the TZ rules change, and that same UTC time is now 10 am local.
That is the EXACT problem that caused my original investigation as to
why TZ data was wrong when there were problems with an international
meeting which involved a live video link ... no one had told the
organisers that DST change may not happen due to I think Ramadan but
certainly some religious event which used the astronomical observations
rather than a calendar date. This was over ten years ago, and these
events now make sure to avoid some periods of the year to prevent
another occurrence, but that is just one example.

> The difficulty with cases like this is that it is not obvious what the desired outcome is.  It might be that I want this event to occur at 9 am local time, and I don't care what that is in UTC.  But it is also possible that I want it to occur at whatever UTC corresponds to 9 am local -- for example, because this is a teleconference with people in several countries.
FLAGGING that there is a potential problem would at least be a help, but
as has been flagged in other posts, printed material such as schedules
and prayer sheets may well be wrong if they have been created using out
of data facts. Deciding what is correct is not a matter for TZ, only
that the facts in version a no longer match the facts in version b.

> It might even be true that the desired answer varies depending on which calendar entry you're looking at.  A dentist appointment is probably strictly in local time; a call with a colleague in another continent is probably primarily in UTC.
Up until quite recently most people probably did not even bother setting
the timezone on their systems. Certainly the systems I was building 15
years ago only had a 24 hour clock and could not run over the DST
change. Switching to a UTC based system eliminates all the problems that
a multi timezone system creates, and one only needs the correct TZ data
for a client location in order to display and add local time events. The
problem that arises is when an event is planned for some future date,
stored normalized, and then the TZ offset gets changed for some reason.
DST changes are the obvious one, and knowing that the event was planned
with version x of the tz data and that version y now applies a different
offset, one can at least identify a problem. If the meeting stays at the
UTC time or moves to a new one is outside of the remit of TZ, but the
fact that TZ has a change is the important bit ... the version used has

> This doesn't feel like a zoneinfo issue; it's a user interface design question for calendar applications.
YES the user interface has to deal with the problem, but if it can't
establish there is a problem because it can't identify that the stored
version is different to the current version of offset then how can the
user interface even warn you there is a problem. It needs to ask if the
versions match ... and it may be that it is dealing with a diary fom a
third source so a centrally sourced reliable version of TZ is critical.

With genealogical data going back in time if your copy of TZ offsets
does not match the one the data is created with who do you even read the
data? Even storing the location data does not help if my copy of TZ has
included backzone and yours does not added to which we have identified a
historical mistake which is fixed in the current version, but not in the
10+ year old version that was used to create the data set. We need
something to identify the copy of data being used at the time and to be
able to access that and check for potential changes. Be that a holy day
that is a week late, or a previously scheduled DST change which has been

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

More information about the tz mailing list