FW: Bulletin C number 38

-----Original Message-----
From: IERS EOP Product Center [mailto:services.iers <at> obspm.fr] 
Sent: Monday, July 06, 2009 12:46
To: adresc1 <at> arcas.obspm.fr
Subject: Bulletin C number 38

     INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) 

SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE
REFERENCE

SERVICE DE LA ROTATION TERRESTRE
OBSERVATOIRE DE PARIS                                   
61, Av. de l'Observatoire 75014 PARIS (France)
Tel.      : 33 (0) 1 40 51 22 26
FAX       : 33 (0) 1 40 51 22 91
Internet  : services.iers <at> obspm.fr

                                               Paris, 4 July 2009

                                               Bulletin C 38

                                               To authorities
responsible                   
                                               for the measurement and 
                                               distribution of time

                          INFORMATION ON UTC - TAI

proposed time zone package changes

Here are proposed time zone package changes, with summary information followed
by the actual changes. If no problems are found, these will appear on the
ftp site in nine days.

				--ado

*	zic.c
		Do not end a binary file with a POSIX-style time zone string
		for locations that end up in permanent DST
		(thanks to Andreas Schwab).
*	asia
		Arbitrarily cut off Dhaka DST at end of 2009
		(so that a POSIX-style time zone string can appear in the
		Dhaka binary file, and for the benefit of systems with old
		glibc reimplementations of the time zone library that don't
		handle permanent DST correctly).
		Note that another change will be needed once the real end
		date for DST in Dhaka is known.
*	africa
		Change Mauritius to reflect that 2008-2009 DST experiment
		is not repeated (and to change end of DST in 2009 from
		2:00 standard time to 2:00 local time)
		(thanks to Steffen Thorsen).
*	europe
		Update URL for Directive 2000/84/EC on summer-time arrangements
		(thanks to Colin Watson and Ian Jackson).
*	leapseconds
		Change "no leap second" comment (no leap second at end of 2009).
*	tz-art.htm
		Add notes on "A Matter of Life and Death"

Re: proposed time zone package changes

On 11-Jul-2009, Arthur David Olson wrote:

> Here are proposed time zone package changes, with summary information followed
> by the actual changes. If no problems are found, these will appear on the
> ftp site in nine days.
> 
> 				--ado

> *	zic.c
> 		Do not end a binary file with a POSIX-style time zone string
> 		for locations that end up in permanent DST
> 		(thanks to Andreas Schwab).

I should have written this when Andreas Schwab first wrote his note, but I forgot to do it.

I disagree with this.  When a region does not observe DST at all, 
the POSIX string simply indicates its abbreviation and offset, 
e.g. UTC0 or EST5.   When a region observes DST all year, it's 
the same as observing the standard time of the next time zone 
eastward all year.   In my opinion, it should simply be coded 
that way.  

Please reconsider.

Dave Cantor
Groton, CT

Re: proposed time zone package changes

Re: proposed time zone package changes

    Date:        Sat, 11 Jul 2009 14:07:35 -0400
    From:        "Dave Cantor" <Dave <at> Cantor.mv.com>
    Message-ID:  <4A58D4E7.20949.B6C0C36 <at> Dave.Cantor.mv.com>

  | I disagree with this.  When a region does not observe DST at all, 
  | the POSIX string simply indicates its abbreviation and offset, 
  | e.g. UTC0 or EST5.   When a region observes DST all year, it's 
  | the same as observing the standard time of the next time zone 
  | eastward all year.   In my opinion, it should simply be coded 
  | that way.  

As I understand it, the issue is to deal with regions with time zone
specifications that cover things that POSIX strings cannot represent.

That is neither regions that have no summer time, nor regions that
have "summer time all year" (ie: are not in the time zone that would be
logically appropriate, I assume).

I'm no expert on POSIX strings, but I think the example that caused
the problem was a region that switched summer time on, but never
switched it off again - that is (so we were told, and I am willing to
accept without evidence to the contrrary) something that POSIX strings
just do not handle.

Of course, this time, the "never switched it off" is just our way of
currently encoding "no-one has yet even hinted at the end date, so we
have no idea what to put", which is why the other half of ado's proposed
fix was just to stick an arbitrary end date on Dhaka's summer time, so the
problem case goes away for people who don't have the other fix).

After all this, I'm not sure what you're objecting to?  There are two
relevant (proposed) changes - one to just not include a POSIX string when
it is impossible to make a valid one (if you object to that, why?  And what
would your alternative be - including invalid strings isn't useful for
anyone.)   The other is the arbitrary end date for summer time for Dhaka
(Bangladesh) - that one makes me a little queasy, but I'm not sure what
else to do to handle people who have old implementations of zic, and so
can't get the benefit of the former fix.  If your objection was to
picking an arbitrary date, then is it better to leave those people with
compiled files with invalidly formatted data?   Or, if the objection is
just to the date picked, suggest a better one - we can probably do
better than "the end of the year" as a guess, though the closer we come
to reasonable the more likely it is that someone will believe that our
arbitrary guess is actually based upon some reliable data.  The one time
that you can be pretty much sure that no-one, however stupid the politicians
are, is ever going to pick to end summer time is midnight, local time,
new year's eve (ie: 00:00 Jan 1) - as no-one is going to want to deal
with what it means (or the cost of fireworks) with having two year
ends occurring just an hour apart...

kre

Re: proposed time zone package changes

On 13-Jul-2009, Robert Elz wrote:

From:	Robert Elz <kre <at> munnari.OZ.AU>
Date sent:	Mon, 13 Jul 2009 16:54:56 +0700

>     Date:        Sat, 11 Jul 2009 14:07:35 -0400
>     From:        "Dave Cantor" <Dave <at> Cantor.mv.com>
>     Message-ID:  <4A58D4E7.20949.B6C0C36 <at> Dave.Cantor.mv.com>
> 
>   | I disagree with this.  When a region does not observe DST at all, 
>   | the POSIX string simply indicates its abbreviation and offset, 
>   | e.g. UTC0 or EST5.   When a region observes DST all year, it's 
>   | the same as observing the standard time of the next time zone 
>   | eastward all year.   In my opinion, it should simply be coded 
>   | that way.  
> 
> As I understand it, the issue is to deal with regions with time zone
> specifications that cover things that POSIX strings cannot represent.
> 
> That is neither regions that have no summer time, nor regions that
> have "summer time all year" (ie: are not in the time zone that would be
> logically appropriate, I assume).
> 
> I'm no expert on POSIX strings, but I think the example that caused
> the problem was a region that switched summer time on, but never
> switched it off again - that is (so we were told, and I am willing to
> accept without evidence to the contrrary) something that POSIX strings
> just do not handle.
> 
> Of course, this time, the "never switched it off" is just our way of
> currently encoding "no-one has yet even hinted at the end date, so we
> have no idea what to put", which is why the other half of ado's proposed
> fix was just to stick an arbitrary end date on Dhaka's summer time, so the
> problem case goes away for people who don't have the other fix).
> 
> After all this, I'm not sure what you're objecting to?  There are two
> relevant (proposed) changes - one to just not include a POSIX string when
> it is impossible to make a valid one (if you object to that, why?  And what
> would your alternative be - including invalid strings isn't useful for
> anyone.)   The other is the arbitrary end date for summer time for Dhaka
> (Bangladesh) - that one makes me a little queasy, but I'm not sure what
> else to do to handle people who have old implementations of zic, and so
> can't get the benefit of the former fix.  If your objection was to
> picking an arbitrary date, then is it better to leave those people with
> compiled files with invalidly formatted data?   Or, if the objection is
> just to the date picked, suggest a better one - we can probably do
> better than "the end of the year" as a guess, though the closer we come
> to reasonable the more likely it is that someone will believe that our
> arbitrary guess is actually based upon some reliable data.  The one time
> that you can be pretty much sure that no-one, however stupid the politicians
> are, is ever going to pick to end summer time is midnight, local time,
> new year's eve (ie: 00:00 Jan 1) - as no-one is going to want to deal
> with what it means (or the cost of fireworks) with having two year
> ends occurring just an hour apart...

What I'm objecting to is not generating a POSIX-style TZ string 
when it is possible to do so.   It seems to me that the string 
"XDT-2" would be a workable TZ string for an exemplary fictitious 
location Fictitious/Xyzzy located 1 hour east of UTC, but using a 
time 2 hours east of UTC all year.

Maybe I'm missing some key point (other than that POSIX TZ 
strings are insufficient for expressing all the rules that 
political entities actually enact).

Dave C.

Re: proposed time zone package changes

Re: proposed time zone package changes

    Date:        Mon, 13 Jul 2009 06:38:02 -0700
    From:        Jonathan Leffler <jonathan.leffler <at> gmail.com>
    Message-ID:  <844b8e1c0907130638l21476d1bw61f78d565664ddd4 <at> mail.gmail.com>

  | The database would surely just need to encode things so that at some point
  | in time after the move to 'permanent summer time', the TZ string would
  | simply be:
  | 
  |     TZ=XYZ-9

yes, between when I sent my reply, and then receiving Dave's and then your
replies I understood better what you're meaning.

Currently, to handle times into perpetuity, zic installs a POSIX type
string to represent times beyond those explicitly encoded into the
binary file, ans so allows localtime() to attempt to make a better
guess at (far) future timestamps than if it were to simply assume
continuous standard time (or something).

It (currently) does that by assuming that the final year about which
data is known (well, guessed) should apply in all future years.
That's what is failing here, Dhaka's current rule simply cannot apply
every year.

For this case, I don't actually think it matters one way or the other,
we can be 99.99% confident that we're going to be generating incorrect
timestamps for Dhaka (and the rest of Bangladesh) for times later in
2009 - that we keep doing that further into the future hardly seems like
a big problem.

But in general, Dave's suggested solution does seem like it might be
better - to handle a genuine case of a zone which decided to switch
to 100% summer time during some year (after which there would be no
more explicit rules of course).

That also perhaps suggests a better solution for Dhaka now, than the
one ado proposed - a zone that switches to summer time, and never
switches back, is just a zone that changes its base timezone.
That weve seen and handled before, in fact as essemtially all zones
start with their LMT zone data, for the period before the introduction
of standard time, maybe a better (short term) fix for Dhaka, would be
to simply encode its 1009 summer time switch on as a timezone change for
now (along with a zone name abbreviation change) - the effect visible
externally should be the same, but we'd be back in familiar territory,
and not need the fictitious end data, and the code) (even old code)
should be able to handle it OK.

When we know when summer time in Bangladesh is set to end, the
representation can be changed back to being a normal summer time on/off
set of transitions.

  | This problem faces all the data.  There is no assigned date for when the USA
  | will next change its rules, but I'm sure it will happen, and probably before
  | I retire.

Sure, but there is a difference in degree...   for the US (and Europe,
Australia, and most other places) there's a fair degree of confidence
that the rules we have are plausible, and until there's specific ation
taken to change them, using that data into the future is as good as
is possible to do.

For the Dhaka ruleset, we know (well, assume with a high degree of confidence)
that sometime, probably September or October sometime, they will switch
back to standard time - they just seem to have not yet selected when
that should happen (or if they have, they're not telling us).  (How the
airlines cope with this I hate to imagine).

Recall the problems we had in Argentine when we didn't have the exact
correct date for their transition, and the annoyance that caused people,
because we had at least a reaosnable assumption encoded in the rules.
Encoding random (unreasonable) guesses would be even worse.

  | I'm not convinced there is no valid TZ string...the outline value I showed
  | would be correct (the same as it is for UTC0).

Yes, the "no valid" assumes the current practice of assuming that the
last year for which we have rules should continue forward indefinitely.

  | The arbitrary end date is probably a necessary fiction, like the fiction
  | that the rules in the USA won't change in the future.

Not quite the same, and if we were to switch the way the change on June 19
is represented in the rules, and make it be a time zone alteration, rather
than a summer time start, then I think we don't need the fiction to
allow zic to work correctly.

kre

RE: proposed time zone package changes

In a "permanent DST" situation, a POSIX TZ string such as...
	TZ=XDST9
...can get almost everything right, but the tm_isdst indicator in tm
structs will end up being set to zero.

				--ado
	

Re: proposed time zone package changes

    Date:        Mon, 13 Jul 2009 10:30:20 -0400
    From:        "Olson, Arthur David (NIH/NCI) [E]" <olsona <at> dc37a.nci.nih.gov>
    Message-ID:  <B410D30A78C6404C9DABEA31B54A2813029A0753 <at> nihcesmlbx10.nih.gov>

  | In a "permanent DST" situation, a POSIX TZ string such as...
  | 	TZ=XDST9
  | ...can get almost everything right, but the tm_isdst indicator in tm
  | structs will end up being set to zero.

That would apply to my suggestion as well - but does it matter?
That is, we're quite prepared to generate what we are almost certain
are incorrect timestamp results, and then we quibble about whether or
not the incorrect answer is "correctly" pretending to be summer time ??

Any real permanent switch (Dhaka's isn't really intended, that seems clear)
would be implemented as a zone change, not permanent summer time anyway
(by everyone, not just us).   That's the way the changes in the US zones
were implemented (the ones that recently jumped from one timezone to
another).  To ease the change for residents, it was explained as "we
just won't set the clocks back when everyone else does" (or so I understand
it) but no-one really considered this to be summer time in perpetuity.

To do better at this for this year though, than what I suggested in the
last message, we could leave Dhaka as a switch to summer time on June 19,
then pick some plausible date (end of October perhaps) for a switch back
to summer time, encode that switch, and then same instant, switch the
time zone one hour ahead.  That way (aside from the tm_isdst value) we
get the same effect as now, without upsetting old zic's, and without
needing a fictional (visible) switch back event included.

kre