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" (thanks to Dave Cantor). * tz-link.htm Remove seemingly obsolete public.planetmirror.com/pub/timezone link (thanks to Nathan Stratton Treadway). diff -c old/africa new/africa *** old/africa Sun May 17 14:32:58 2009 --- new/africa Sat Jul 11 12:07:03 2009 *************** *** 1,5 **** # <pre> ! # @(#)africa 8.21 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. --- 1,5 ---- # <pre> ! # @(#)africa 8.22 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. *************** *** 502,512 **** # http://www.gov.mu/portal/goc/assemblysite/file/bill2708.pdf # </a> # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Mauritius 1982 only - Oct 10 0:00 1:00 S Rule Mauritius 1983 only - Mar 21 0:00 0 - ! Rule Mauritius 2008 max - Oct lastSun 2:00s 1:00 S ! Rule Mauritius 2009 max - Mar lastSun 2:00s 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Indian/Mauritius 3:50:00 - LMT 1907 # Port Louis 4:00 Mauritius MU%sT # Mauritius Time --- 502,534 ---- # http://www.gov.mu/portal/goc/assemblysite/file/bill2708.pdf # </a> + # From Steffen Thorsen (2009-06-05): + # According to several sources, Mauritius will not continue to observe + # DST the coming summer... + # + # Some sources, in French: + # <a href="http://www.defimedia.info/news/946/Rashid-Beebeejaun-:-%C2%AB-L%E2%80%99heure-d%E2%80%99%C3%A9t%C3%A9-ne-sera-pas-appliqu%C3%A9e-cette-ann%C3%A9e-%C2%BB"> + # http://www.defimedia.info/news/946/Rashid-Beebeejaun-:-%C2%AB-L%E2%80%99heur... + # </a> + # <a href="http://lexpress.mu/Story/3398~Beebeejaun---Les-objectifs-d-%C3%A9conomie-d-%C3%A9nergie-de-l-heure-d-%C3%A9t%C3%A9-ont-%C3%A9t%C3%A9-atteints-"> + # http://lexpress.mu/Story/3398~Beebeejaun---Les-objectifs-d-%C3%A9conomie-d-%... + # </a> + # + # Our wrap-up: + # <a href="http://www.timeanddate.com/news/time/mauritius-dst-will-not-repeat.html"> + # http://www.timeanddate.com/news/time/mauritius-dst-will-not-repeat.html + # </a> + + # From Arthur David Olson (2009-07-11): + # The "mauritius-dst-will-not-repeat" wrapup includes this: + # "The trial ended on March 29, 2009, when the clocks moved back by one hour + # at 2am (or 02:00) local time..." + # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Mauritius 1982 only - Oct 10 0:00 1:00 S Rule Mauritius 1983 only - Mar 21 0:00 0 - ! Rule Mauritius 2008 only - Oct lastSun 2:00 1:00 S ! Rule Mauritius 2009 only - Mar lastSun 2:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Indian/Mauritius 3:50:00 - LMT 1907 # Port Louis 4:00 Mauritius MU%sT # Mauritius Time diff -c old/asia new/asia *** old/asia Mon Jun 15 06:43:59 2009 --- new/asia Sat Jul 11 12:07:03 2009 *************** *** 1,5 **** # <pre> ! # @(#)asia 8.35 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. --- 1,5 ---- # <pre> ! # @(#)asia 8.36 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. *************** *** 172,177 **** --- 172,183 ---- # # No DST end date has been announced yet. + # From Arthur David Olson (2009-07-11): + # Arbitrarily end DST at the end of 2009 so that a POSIX-sytle time zone string + # can appear in the Dhaka binary file and for the benefit of old glibc + # reimplementations of the time zone software that mishandle permanent DST. + # A change will be required once the end date is known. + # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Dhaka 6:01:40 - LMT 1890 5:53:20 - HMT 1941 Oct # Howrah Mean Time? *************** *** 180,186 **** 6:30 - BURT 1951 Sep 30 6:00 - DACT 1971 Mar 26 # Dacca Time 6:00 - BDT 2009 Jun 19 23:00 # Bangladesh Time ! 6:00 1:00 BDST # Bhutan # Zone NAME GMTOFF RULES FORMAT [UNTIL] --- 186,193 ---- 6:30 - BURT 1951 Sep 30 6:00 - DACT 1971 Mar 26 # Dacca Time 6:00 - BDT 2009 Jun 19 23:00 # Bangladesh Time ! 6:00 1:00 BDST 2010 ! 6:00 - BDT # Bhutan # Zone NAME GMTOFF RULES FORMAT [UNTIL] diff -c old/europe new/europe *** old/europe Sun May 17 14:32:59 2009 --- new/europe Sat Jul 11 12:09:02 2009 *************** *** 1,5 **** # <pre> ! # @(#)europe 8.21 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. --- 1,5 ---- # <pre> ! # @(#)europe 8.22 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. *************** *** 459,465 **** Rule EU 1981 max - Mar lastSun 1:00u 1:00 S Rule EU 1996 max - Oct lastSun 1:00u 0 - # The most recent directive covers the years starting in 2002. See: ! # <a href="http://europa.eu.int/eur-lex/en/lif/dat/2000/en_300L0084.html"> # Directive 2000/84/EC of the European Parliament and of the Council # of 19 January 2001 on summer-time arrangements. # </a> --- 459,465 ---- Rule EU 1981 max - Mar lastSun 1:00u 1:00 S Rule EU 1996 max - Oct lastSun 1:00u 0 - # The most recent directive covers the years starting in 2002. See: ! # <a="http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32000L0084:EN:NOT"> # Directive 2000/84/EC of the European Parliament and of the Council # of 19 January 2001 on summer-time arrangements. # </a> diff -c old/leapseconds new/leapseconds *** old/leapseconds Sun May 17 14:32:59 2009 --- new/leapseconds Sat Jul 11 12:07:04 2009 *************** *** 1,5 **** # <pre> ! # @(#)leapseconds 8.8 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. --- 1,5 ---- # <pre> ! # @(#)leapseconds 8.9 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. *************** *** 56,68 **** # SERVICE DE LA ROTATION TERRESTRE # OBSERVATOIRE DE PARIS # 61, Av. de l'Observatoire 75014 PARIS (France) ! # Tel. : 33 (0) 1 40 51 22 29 # FAX : 33 (0) 1 40 51 22 91 # Internet : services.iers@obspm.fr # ! # Paris, 15 January 2009 # ! # Bulletin C 37 # # To authorities responsible # for the measurement and --- 56,68 ---- # 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@obspm.fr # ! # Paris, 4 July 2009 # ! # Bulletin C 38 # # To authorities responsible # for the measurement and *************** *** 70,76 **** # # INFORMATION ON UTC - TAI # ! # NO positive leap second will be introduced at the end of June 2009. # The difference between Coordinated Universal Time UTC and the # International Atomic Time TAI is : # --- 70,76 ---- # # INFORMATION ON UTC - TAI # ! # NO positive leap second will be introduced at the end of December 2009. # The difference between Coordinated Universal Time UTC and the # International Atomic Time TAI is : # *************** *** 82,87 **** # will be no time step at the next possible date. # # Daniel GAMBIS ! # Head ! # Earth Orientation Center of the IERS # Observatoire de Paris, France --- 82,87 ---- # will be no time step at the next possible date. # # Daniel GAMBIS ! # Director ! # Earth Orientation Center of IERS # Observatoire de Paris, France diff -c old/tz-art.htm new/tz-art.htm *** old/tz-art.htm Sun May 17 14:44:05 2009 --- new/tz-art.htm Sat Jul 11 12:07:04 2009 *************** *** 9,15 **** <body> <h1>Time and the Arts</h1> <address> ! @(#)tz-art.htm 8.12 </address> <p> This file is in the public domain, so clarified as of --- 9,15 ---- <body> <h1>Time and the Arts</h1> <address> ! @(#)tz-art.htm 8.13 </address> <p> This file is in the public domain, so clarified as of *************** *** 353,358 **** --- 353,369 ---- premonition in the "We Had a Dream" episode of "Medium" (originally aired 2007-02-28). </li> + <li> + In the 1946 "A Matter of Life and Death," + there is a reference to British Double Summer Time. + The time does not play a large part in the plot; + it's just a passing reference to the time when one of the + characters was supposed to have died (but didn't). + The IMDb page is at + <a href="http://us.imdb.com/title/tt0038733/"> + http://us.imdb.com/title/tt0038733/ + </a>. (Dave Cantor) + </li> </ul> <hr> <ul> diff -c old/tz-link.htm new/tz-link.htm *** old/tz-link.htm Sat Jun 6 08:27:24 2009 --- new/tz-link.htm Sat Jul 11 12:07:04 2009 *************** *** 18,24 **** <body> <h1>Sources for Time Zone and Daylight Saving Time Data</h1> <address> ! @(#)tz-link.htm 8.21 </address> <p> This file is in the public domain, so clarified as of --- 18,24 ---- <body> <h1>Sources for Time Zone and Daylight Saving Time Data</h1> <address> ! @(#)tz-link.htm 8.22 </address> <p> This file is in the public domain, so clarified as of *************** *** 114,123 **** href="ftp://elsie.nci.nih.gov/pub/tzarchive.gz">full archive of old messages</a> (in gzip compressed format), or retrieve <a href="ftp://munnari.oz.au/pub/oldtz">archived older versions of code ! and data</a>; there is also a smaller <a ! href="http://public.planetmirror.com/pub/timezone"><abbr ! title="Hypertext Transfer Protocol">HTTP</abbr> ! mirror</a>.</p> <p> The Web has several other sources for time zone and daylight saving time data. Here are some recent links that may be of interest. --- 114,120 ---- href="ftp://elsie.nci.nih.gov/pub/tzarchive.gz">full archive of old messages</a> (in gzip compressed format), or retrieve <a href="ftp://munnari.oz.au/pub/oldtz">archived older versions of code ! and data</a>.</p> <p> The Web has several other sources for time zone and daylight saving time data. Here are some recent links that may be of interest. diff -c old/zic.c new/zic.c *** old/zic.c Mon Apr 20 16:17:54 2009 --- new/zic.c Sat Jul 11 12:07:04 2009 *************** *** 3,9 **** ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.19"; #include "private.h" #include "locale.h" --- 3,9 ---- ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.20"; #include "private.h" #include "locale.h" *************** *** 1921,1927 **** if (stdrp != NULL && stdrp->r_hiyear == 2037) return; } ! if (stdrp == NULL && zp->z_nrules != 0) return; abbrvar = (stdrp == NULL) ? "" : stdrp->r_abbrvar; doabbr(result, zp->z_format, abbrvar, FALSE, TRUE); --- 1921,1927 ---- if (stdrp != NULL && stdrp->r_hiyear == 2037) return; } ! if (stdrp == NULL && (zp->z_nrules != 0 || zp->z_stdoff != 0)) return; abbrvar = (stdrp == NULL) ? "" : stdrp->r_abbrvar; doabbr(result, zp->z_format, abbrvar, FALSE, TRUE);
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
On Sat, Jul 11, 2009 at 11:07 AM, Dave Cantor <Dave@cantor.mv.com> wrote:
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.
Seconded... -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused." Resent - to correct email address...Prior attempt dated 2009-07-11.
Date: Sat, 11 Jul 2009 14:07:35 -0400 From: "Dave Cantor" <Dave@Cantor.mv.com> Message-ID: <4A58D4E7.20949.B6C0C36@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
On 13-Jul-2009, Robert Elz wrote: From: Robert Elz <kre@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@Cantor.mv.com> Message-ID: <4A58D4E7.20949.B6C0C36@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.
On Mon, Jul 13, 2009 at 2:54 AM, Robert Elz <kre@munnari.oz.au> wrote:
Date: Sat, 11 Jul 2009 14:07:35 -0400 From: "Dave Cantor" <Dave@Cantor.mv.com> Message-ID: <4A58D4E7.20949.B6C0C36@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.
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 for a suitable code XYZ and timezone offset. This would apply all year round in perpetuity. In the year when the switch occurred, the Olson database would encode the rules appropriately - it can surely handle a year where there is just one change to the time zone offset.
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).
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.
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.)
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). The fact that the time zone offset that is used indefinitely used to correspond to a daylight saving time zone offset for the same region is neither here nor there - for the indefinite future, the time zone for the country becomes a simple fixed offset from UTC all year round (something that POSIX TZ strings can manage trivially).
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...
The arbitrary end date is probably a necessary fiction, like the fiction that the rules in the USA won't change in the future. -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
Date: Mon, 13 Jul 2009 06:38:02 -0700 From: Jonathan Leffler <jonathan.leffler@gmail.com> Message-ID: <844b8e1c0907130638l21476d1bw61f78d565664ddd4@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
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
Date: Mon, 13 Jul 2009 10:30:20 -0400 From: "Olson, Arthur David (NIH/NCI) [E]" <olsona@dc37a.nci.nih.gov> Message-ID: <B410D30A78C6404C9DABEA31B54A2813029A0753@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
On 13-Jul-2009, Olson, Arthur David (NIH/NCI) wrote:
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.
Yes, that's true. I consider this to be yet another effect of the fact that POSIX TZ strings cannot encode all the rules that people can legislate. Maybe we need a kludge like TZ=XST10XDST,J0,J999 to indicate that DST is in use all year. That doesn't comply with POSIX, though, and using J1/0,J365/23:59:59 does, but implies transitions which do not occur. What TZ string did people use in the United States in the 1973, when we stayed on DST all year? Was Eastern Time specified as EDT4? Did we have computers back then? :-) Dave C.
On Mon, Jul 13, 2009 at 7:30 AM, Olson, Arthur David (NIH/NCI) [E] < olsona@dc37a.nci.nih.gov> wrote:
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.
How significant is that one bit (or do I mean zero bit?)? The purpose of tm_isdst is primarily to indicate which of two possible timezone names (abbreviations) should be used, isn't it? And if there is only one, then having tm_isdst always set to zero will indicate "use the only zone abbreviation", won't it? -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
participants (5)
-
Arthur David Olson -
Dave Cantor -
Jonathan Leffler -
Olson, Arthur David (NIH/NCI) [E] -
Robert Elz