[PATCH] Updates for Chile 2013
--- Hi there, this is a patch for the Chile update that others have brought up. I decided to apply the transition dates to single years only--the DST policy is reevaluated every year anyway. Thanks, PM antarctica | 4 ++-- southamerica | 21 +++++++++++++++++++-- 2 files changed, 21 insertions(+), 4 deletions(-) diff --git a/antarctica b/antarctica index f55cbde..83d6826 100644 --- a/antarctica +++ b/antarctica @@ -52,8 +52,8 @@ Rule ChileAQ 2011 only - May Sun>=2 3:00u 0 - Rule ChileAQ 2011 only - Aug Sun>=16 4:00u 1:00 S Rule ChileAQ 2012 only - Apr Sun>=23 3:00u 0 - Rule ChileAQ 2012 only - Sep Sun>=2 4:00u 1:00 S -Rule ChileAQ 2013 max - Mar Sun>=9 3:00u 0 - -Rule ChileAQ 2013 max - Oct Sun>=9 4:00u 1:00 S +Rule ChileAQ 2013 only - Apr 28 3:00u 0 - +Rule ChileAQ 2013 only - Sep 8 4:00u 1:00 S # These rules are stolen from the `australasia' file. Rule AusAQ 1917 only - Jan 1 0:01 1:00 - diff --git a/southamerica b/southamerica index e4c8720..331c2fd 100644 --- a/southamerica +++ b/southamerica @@ -1237,6 +1237,23 @@ Zone America/Rio_Branco -4:31:12 - LMT 1914 # Note that...this is yet another "temporary" change that will be reevaluated # AGAIN in 2013. +# From Glenn Eychaner (2013-02-15): +# The article: +# <a href="http://www.diarioeldia.cl/articulo/entregan-fechas-cambio-hora-este-2013"> +# http://www.diarioeldia.cl/articulo/entregan-fechas-cambio-hora-este-2013 +# </a> +# +# In English: +# [At] midnight Saturday April 27. That day, the clocks should be +# delayed by 60 minutes, that is, being 23:59 hours and 59 seconds, +# instead of going at 0:00 pm, the time should be adjusted to be the +# same day 23:00. +# +# Turn, will resume DST midnight Saturday September 7. That day, the +# clocks will move forward in 60 minutes, that is, being 23:59 hours +# and 59 seconds, instead of going at 00:00 pm, will adjust the time +# to be 01:00 hours on 8 September. + # NOTE: ChileAQ rules for Antarctic bases are stored separately in the # 'antarctica' file. @@ -1280,8 +1297,8 @@ Rule Chile 2011 only - May Sun>=2 3:00u 0 - Rule Chile 2011 only - Aug Sun>=16 4:00u 1:00 S Rule Chile 2012 only - Apr Sun>=23 3:00u 0 - Rule Chile 2012 only - Sep Sun>=2 4:00u 1:00 S -Rule Chile 2013 max - Mar Sun>=9 3:00u 0 - -Rule Chile 2013 max - Oct Sun>=9 4:00u 1:00 S +Rule Chile 2013 only - Apr 28 3:00u 0 - +Rule Chile 2013 only - Sep 8 4:00u 1:00 S # IATA SSIM anomalies: (1992-02) says 1992-03-14; # (1996-09) says 1998-03-08. Ignore these. # Zone NAME GMTOFF RULES FORMAT [UNTIL] -- 1.7.6.5
I’m not an expert (which is why I didn’t try my hand at it), but it looks like this patch will leave no rules for 2014 onward. Rather than removing the current lines, shouldn’t you move them to the end and make them “2014 max”? Thanks, Deborah On Feb 20, 2013, at 1:55 PM, Petr Machata <pmachata@redhat.com> wrote:
--- Hi there,
this is a patch for the Chile update that others have brought up. I decided to apply the transition dates to single years only--the DST policy is reevaluated every year anyway.
Thanks, PM
antarctica | 4 ++-- southamerica | 21 +++++++++++++++++++-- 2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/antarctica b/antarctica index f55cbde..83d6826 100644 --- a/antarctica +++ b/antarctica @@ -52,8 +52,8 @@ Rule ChileAQ 2011 only - May Sun>=2 3:00u 0 - Rule ChileAQ 2011 only - Aug Sun>=16 4:00u 1:00 S Rule ChileAQ 2012 only - Apr Sun>=23 3:00u 0 - Rule ChileAQ 2012 only - Sep Sun>=2 4:00u 1:00 S -Rule ChileAQ 2013 max - Mar Sun>=9 3:00u 0 - -Rule ChileAQ 2013 max - Oct Sun>=9 4:00u 1:00 S +Rule ChileAQ 2013 only - Apr 28 3:00u 0 - +Rule ChileAQ 2013 only - Sep 8 4:00u 1:00 S
# These rules are stolen from the `australasia' file. Rule AusAQ 1917 only - Jan 1 0:01 1:00 - diff --git a/southamerica b/southamerica index e4c8720..331c2fd 100644 --- a/southamerica +++ b/southamerica @@ -1237,6 +1237,23 @@ Zone America/Rio_Branco -4:31:12 - LMT 1914 # Note that...this is yet another "temporary" change that will be reevaluated # AGAIN in 2013.
+# From Glenn Eychaner (2013-02-15): +# The article: +# <a href="http://www.diarioeldia.cl/articulo/entregan-fechas-cambio-hora-este-2013"> +# http://www.diarioeldia.cl/articulo/entregan-fechas-cambio-hora-este-2013 +# </a> +# +# In English: +# [At] midnight Saturday April 27. That day, the clocks should be +# delayed by 60 minutes, that is, being 23:59 hours and 59 seconds, +# instead of going at 0:00 pm, the time should be adjusted to be the +# same day 23:00. +# +# Turn, will resume DST midnight Saturday September 7. That day, the +# clocks will move forward in 60 minutes, that is, being 23:59 hours +# and 59 seconds, instead of going at 00:00 pm, will adjust the time +# to be 01:00 hours on 8 September. + # NOTE: ChileAQ rules for Antarctic bases are stored separately in the # 'antarctica' file.
@@ -1280,8 +1297,8 @@ Rule Chile 2011 only - May Sun>=2 3:00u 0 - Rule Chile 2011 only - Aug Sun>=16 4:00u 1:00 S Rule Chile 2012 only - Apr Sun>=23 3:00u 0 - Rule Chile 2012 only - Sep Sun>=2 4:00u 1:00 S -Rule Chile 2013 max - Mar Sun>=9 3:00u 0 - -Rule Chile 2013 max - Oct Sun>=9 4:00u 1:00 S +Rule Chile 2013 only - Apr 28 3:00u 0 - +Rule Chile 2013 only - Sep 8 4:00u 1:00 S # IATA SSIM anomalies: (1992-02) says 1992-03-14; # (1996-09) says 1998-03-08. Ignore these. # Zone NAME GMTOFF RULES FORMAT [UNTIL] -- 1.7.6.5
Deborah Goldsmith <goldsmit@apple.com> writes:
I’m not an expert (which is why I didn’t try my hand at it), but it looks like this patch will leave no rules for 2014 onward. Rather than removing the current lines, shouldn’t you move them to the end and make them “2014 max”?
I decided to apply the transition dates to single years only--the DST policy is reevaluated every year anyway. PM
Date: Wed, 20 Feb 2013 22:55:04 +0100 From: Petr Machata <pmachata@redhat.com> Message-ID: <m2ehgaljwl.fsf@redhat.com> | I decided to apply the transition dates to single years only--the DST | policy is reevaluated every year anyway. I think that's a mistake - you're guaranteeing that the data is going to be wrong, rather than simply making it likely. I'd suggest that the data be changed as ... --- southamerica.was 2012-07-25 21:13:46.000000000 +0700 +++ southamerica 2013-02-21 07:37:16.000000000 +0700 @@ -1277,10 +1277,8 @@ Rule Chile 2010 only - Apr Sun>=1 3:00u 0 - Rule Chile 2011 only - May Sun>=2 3:00u 0 - Rule Chile 2011 only - Aug Sun>=16 4:00u 1:00 S -Rule Chile 2012 only - Apr Sun>=23 3:00u 0 - -Rule Chile 2012 only - Sep Sun>=2 4:00u 1:00 S -Rule Chile 2013 max - Mar Sun>=9 3:00u 0 - -Rule Chile 2013 max - Oct Sun>=9 4:00u 1:00 S +Rule Chile 2012 max - Apr Sun>=23 3:00u 0 - +Rule Chile 2012 max - Sep Sun>=2 4:00u 1:00 S # IATA SSIM anomalies: (1992-02) says 1992-03-14; # (1996-09) says 1998-03-08. Ignore these. # Zone NAME GMTOFF RULES FORMAT [UNTIL] That is, it turns out that the rules we inserted for 2012 apply for 2013 as well (except we were conservative last year, and assumed the change then was just a one year thing, and put the older dates back for 2013). So, the patch above just assumes that the 2012/2013 strategy will continue forwards, which it might ... it is also possible that it won't, and we will need to change it again next year (or even again later this year) but some kind of reasonable guess is better than simply assuming that summer time is going to start next September, and then never end. kre
On 02/20/2013 04:42 PM, Robert Elz wrote:
So, the patch above just assumes that the 2012/2013 strategy will continue forwards
Thanks, that sounds like the best guess. I'll soon send out a proposed patch along these lines. Along with this I'll send out some lower-priority patches that have been accumulating. The only other patch worth noting is one that will allow 24:00 as a valid UTC offset in the POSIX string at the end of binary version-2-format time zone files. Formerly, zic limited this to 23:59:59, but the 2008 edition of POSIX changed to allow 24:00 and tzfile.5 specifies POSIX so this will fix zic to match the documented behavior. People who write binary tz file readers may need to adjust them accordingly. There should be 7 proposed patches total. I've updated the github experimental repository to contain these patches.
Hi, Is there an ETA for when 2013a might be released? Thank you, Deborah Goldsmith On Feb 20, 2013, at 11:50 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
On 02/20/2013 04:42 PM, Robert Elz wrote:
So, the patch above just assumes that the 2012/2013 strategy will continue forwards
Thanks, that sounds like the best guess. I'll soon send out a proposed patch along these lines. Along with this I'll send out some lower-priority patches that have been accumulating. The only other patch worth noting is one that will allow 24:00 as a valid UTC offset in the POSIX string at the end of binary version-2-format time zone files. Formerly, zic limited this to 23:59:59, but the 2008 edition of POSIX changed to allow 24:00 and tzfile.5 specifies POSIX so this will fix zic to match the documented behavior. People who write binary tz file readers may need to adjust them accordingly.
There should be 7 proposed patches total. I've updated the github experimental repository to contain these patches.
I echo this ETA request. We need to get this patch installed next week. Or at least before 8 March 2013, when all non-patched systems will "fall" back. We also need to let other teams have time to create patches (Apache, PHP, Java, Oracle, etc). Cheers, ========================================================================= Richard Gombert Senior Technical Specialist RDE & Q - IT - Global Manufacturing D/450D 330.796.4036 GTN: 447-4036 Mailing address: PO Box 3531 (200 Innovation Way) Akron, OH 44309-3531 Shipping address: Goodyear Tire & Rubber Co. Receiving D/530A, Bldg. 72 Attn: Richard Gombert, D/450D 1376 Tech Way Drive Akron, Ohio 44306 Contains Confidential and/or Proprietary Information. May Not Be Copied or Disseminated Without Express Consent of The Goodyear Tire & Rubber Company ========================================================================= From: Deborah Goldsmith <goldsmit@apple.com> To: Paul Eggert <eggert@cs.ucla.edu>, Cc: tz@iana.org, Robert Elz <kre@munnari.OZ.AU> Date: 02/25/2013 07:27 PM Subject: Re: [tz] [PATCH] Updates for Chile 2013 Sent by: tz-bounces@iana.org Hi, Is there an ETA for when 2013a might be released? Thank you, Deborah Goldsmith On Feb 20, 2013, at 11:50 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
On 02/20/2013 04:42 PM, Robert Elz wrote:
So, the patch above just assumes that the 2012/2013 strategy will continue forwards
Thanks, that sounds like the best guess. I'll soon send out a proposed patch along these lines. Along with this I'll send out some lower-priority patches that have been accumulating. The only other patch worth noting is one that will allow 24:00 as a valid UTC offset in the POSIX string at the end of binary version-2-format time zone files. Formerly, zic limited this to 23:59:59, but the 2008 edition of POSIX changed to allow 24:00 and tzfile.5 specifies POSIX so this will fix zic to match the documented behavior. People who write binary tz file readers may need to adjust them accordingly.
There should be 7 proposed patches total. I've updated the github experimental repository to contain these patches.
We, too, would benefit from having this update, or at least the Chile changes part of it, formally released as soon as practical. -- Andy Heninger On Tue, Feb 26, 2013 at 9:37 AM, <richard_gombert@goodyear.com> wrote:
I echo this ETA request.
We need to get this patch installed next week. Or at least before 8 March 2013, when all non-patched systems will "fall" back.
We also need to let other teams have time to create patches (Apache, PHP, Java, Oracle, etc).
Cheers,
=========================================================================
Richard Gombert
Senior Technical Specialist
RDE & Q - IT - Global Manufacturing D/450D
330.796.4036
GTN: 447-4036
*Mailing address:*
PO Box 3531 (200 Innovation Way)
Akron, OH 44309-3531 *Shipping address: *
Goodyear Tire & Rubber Co.
Receiving D/530A, Bldg. 72
Attn: Richard Gombert, D/450D
1376 Tech Way Drive
Akron, Ohio 44306
Contains Confidential and/or Proprietary Information.
May Not Be Copied or Disseminated Without Express
Consent of The Goodyear Tire & Rubber Company
=========================================================================
From: Deborah Goldsmith <goldsmit@apple.com> To: Paul Eggert <eggert@cs.ucla.edu>, Cc: tz@iana.org, Robert Elz <kre@munnari.OZ.AU> Date: 02/25/2013 07:27 PM Subject: Re: [tz] [PATCH] Updates for Chile 2013 Sent by: tz-bounces@iana.org ------------------------------
Hi,
Is there an ETA for when 2013a might be released?
Thank you, Deborah Goldsmith
On Feb 20, 2013, at 11:50 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
On 02/20/2013 04:42 PM, Robert Elz wrote:
So, the patch above just assumes that the 2012/2013 strategy will continue forwards
Thanks, that sounds like the best guess. I'll soon send out a proposed patch along these lines. Along with this I'll send out some lower-priority patches that have been accumulating. The only other patch worth noting is one that will allow 24:00 as a valid UTC offset in the POSIX string at the end of binary version-2-format time zone files. Formerly, zic limited this to 23:59:59, but the 2008 edition of POSIX changed to allow 24:00 and tzfile.5 specifies POSIX so this will fix zic to match the documented behavior. People who write binary tz file readers may need to adjust them accordingly.
There should be 7 proposed patches total. I've updated the github experimental repository to contain these patches.
The new version should be available soon. In the meantime your folks can test with what's on github, as that's likely going to be the final version, except that the version number will be updated to 2013a. To be honest one holdup at this point is the hassle of jumping through all the internal security hoops to create an official release. It's an unpleasant process and I dread having to do it. There is some benefit to not being hasty, I suppose.
Thank you, Paul, for all that you do in keeping this going. I really appreciate it. -- Andy On Tue, Feb 26, 2013 at 12:55 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
The new version should be available soon. In the meantime your folks can test with what's on github, as that's likely going to be the final version, except that the version number will be updated to 2013a.
To be honest one holdup at this point is the hassle of jumping through all the internal security hoops to create an official release. It's an unpleasant process and I dread having to do it. There is some benefit to not being hasty, I suppose.
The same here! Deborah On Feb 26, 2013, at 1:59 PM, Andy Heninger <aheninger@google.com> wrote:
Thank you, Paul, for all that you do in keeping this going. I really appreciate it.
-- Andy
On Tue, Feb 26, 2013 at 12:55 PM, Paul Eggert <eggert@cs.ucla.edu> wrote: The new version should be available soon. In the meantime your folks can test with what's on github, as that's likely going to be the final version, except that the version number will be updated to 2013a.
To be honest one holdup at this point is the hassle of jumping through all the internal security hoops to create an official release. It's an unpleasant process and I dread having to do it. There is some benefit to not being hasty, I suppose.
Hi, Is there anything any of us can do to assist in this? Thanks, Deborah On Feb 26, 2013, at 12:55 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
The new version should be available soon. In the meantime your folks can test with what's on github, as that's likely going to be the final version, except that the version number will be updated to 2013a.
To be honest one holdup at this point is the hassle of jumping through all the internal security hoops to create an official release. It's an unpleasant process and I dread having to do it. There is some benefit to not being hasty, I suppose.
Agreed. Please let us know if we can help. I have a standard outage window this weekend to apply the update. If we don't make that I have to arrange for an emergency change and a plant wide shutdown to update the dozen or so plant floor systems. Yes the OS update does not usually require a reboot, but the application that run on those OS's do. So we have to shutdown the whole plant. Major headache for me. Thanks, ========================================================================= Richard Gombert Senior Technical Specialist RDE & Q - IT - Global Manufacturing D/450D 330.796.4036 GTN: 447-4036 Mailing address: PO Box 3531 (200 Innovation Way) Akron, OH 44309-3531 Shipping address: Goodyear Tire & Rubber Co. Receiving D/530A, Bldg. 72 Attn: Richard Gombert, D/450D 1376 Tech Way Drive Akron, Ohio 44306 Contains Confidential and/or Proprietary Information. May Not Be Copied or Disseminated Without Express Consent of The Goodyear Tire & Rubber Company ========================================================================= From: Deborah Goldsmith <goldsmit@apple.com> To: Paul Eggert <eggert@cs.ucla.edu>, Cc: Time Zone Database discussion <tz@iana.org>, Robert Elz <kre@munnari.oz.au> Date: 02/28/2013 04:53 PM Subject: Re: [tz] [PATCH] Updates for Chile 2013 Sent by: tz-bounces@iana.org Hi, Is there anything any of us can do to assist in this? Thanks, Deborah On Feb 26, 2013, at 12:55 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
The new version should be available soon. In the meantime your folks can test with what's on github, as that's likely going to be the final version, except that the version number will be updated to 2013a.
To be honest one holdup at this point is the hassle of jumping through all the internal security hoops to create an official release. It's an unpleasant process and I dread having to do it. There is some benefit to not being hasty, I suppose.
I believe the implication of Paul's message is that, to help, you could test the version of tzdata currently available to you in the github repository. He says this is likely the "final version", so of course, if your testing shows any problems, it is better to do it now rather than after it is released. If it does not show any problems, then perhaps you can use it in production even before the official release is made. Regards, Malcolm From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of richard_gombert@goodyear.com Sent: 01 March 2013 13:55 To: Time Zone Database discussion; tz-bounces@iana.org Subject: Re: [tz] [PATCH] Updates for Chile 2013 Agreed. Please let us know if we can help. I have a standard outage window this weekend to apply the update. If we don't make that I have to arrange for an emergency change and a plant wide shutdown to update the dozen or so plant floor systems. Yes the OS update does not usually require a reboot, but the application that run on those OS's do. So we have to shutdown the whole plant. Major headache for me. Thanks, ========================================================================= Richard Gombert Senior Technical Specialist RDE & Q - IT - Global Manufacturing D/450D 330.796.4036 GTN: 447-4036 Mailing address: PO Box 3531 (200 Innovation Way) Akron, OH 44309-3531 Shipping address: Goodyear Tire & Rubber Co. Receiving D/530A, Bldg. 72 Attn: Richard Gombert, D/450D 1376 Tech Way Drive Akron, Ohio 44306 Contains Confidential and/or Proprietary Information. May Not Be Copied or Disseminated Without Express Consent of The Goodyear Tire & Rubber Company ========================================================================= From: Deborah Goldsmith <goldsmit@apple.com> To: Paul Eggert <eggert@cs.ucla.edu>, Cc: Time Zone Database discussion <tz@iana.org>, Robert Elz <kre@munnari.oz.au> Date: 02/28/2013 04:53 PM Subject: Re: [tz] [PATCH] Updates for Chile 2013 Sent by: tz-bounces@iana.org ________________________________ Hi, Is there anything any of us can do to assist in this? Thanks, Deborah On Feb 26, 2013, at 12:55 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
The new version should be available soon. In the meantime your folks can test with what's on github, as that's likely going to be the final version, except that the version number will be updated to 2013a.
To be honest one holdup at this point is the hassle of jumping through all the internal security hoops to create an official release. It's an unpleasant process and I dread having to do it. There is some benefit to not being hasty, I suppose.
This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html.
I can't speak for everyone, but I can at least speak for my production systems -- We have a production process based around IANA releases. This process can not depend on github snapshots. We need lead time to deploy a real IANA release to thousands of boxes in a safe manner. We can do testing using github, but that doesn't remove the need to get a regularly scheduled (as in "everyone knew about the Chile changes weeks ago") update at least a week in advance. If there is anything that the community can do help the release process, please let us know. -Andrew On Fri, Mar 1, 2013 at 9:15 AM, Wallace, Malcolm <Malcolm.Wallace@sc.com>wrote:
I believe the implication of Paul’s message is that, to help, you could test the version of tzdata currently available to you in the github repository. He says this is likely the “final version”, so of course, if your testing shows any problems, it is better to do it now rather than after it is released. If it does not show any problems, then perhaps you can use it in production even before the official release is made.****
** **
Regards,****
Malcolm****
** **
*From:* tz-bounces@iana.org [mailto:tz-bounces@iana.org] *On Behalf Of * richard_gombert@goodyear.com *Sent:* 01 March 2013 13:55 *To:* Time Zone Database discussion; tz-bounces@iana.org
*Subject:* Re: [tz] [PATCH] Updates for Chile 2013****
** **
Agreed.
Please let us know if we can help.
I have a standard outage window this weekend to apply the update.
If we don't make that I have to arrange for an emergency change and a plant wide shutdown to update the dozen or so plant floor systems.
Yes the OS update does not usually require a reboot, but the application that run on those OS's do. So we have to shutdown the whole plant. Major headache for me.
Thanks, ** **
========================================================================= ** **
Richard Gombert ****
Senior Technical Specialist ****
RDE & Q - IT - Global Manufacturing D/450D ****
330.796.4036 ****
GTN: 447-4036 ****
*Mailing address:* ****
PO Box 3531 (200 Innovation Way) ****
Akron, OH 44309-3531 ****
*Shipping address: *****
Goodyear Tire & Rubber Co. ****
Receiving D/530A, Bldg. 72 ****
Attn: Richard Gombert, D/450D ****
1376 Tech Way Drive ****
Akron, Ohio 44306****
** **
Contains Confidential and/or Proprietary Information. ****
May Not Be Copied or Disseminated Without Express ****
Consent of The Goodyear Tire & Rubber Company ****
=========================================================================
From: Deborah Goldsmith <goldsmit@apple.com> To: Paul Eggert <eggert@cs.ucla.edu>, Cc: Time Zone Database discussion <tz@iana.org>, Robert Elz < kre@munnari.oz.au> Date: 02/28/2013 04:53 PM Subject: Re: [tz] [PATCH] Updates for Chile 2013 Sent by: tz-bounces@iana.org **** ------------------------------
Hi,
Is there anything any of us can do to assist in this?
Thanks, Deborah
On Feb 26, 2013, at 12:55 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
The new version should be available soon. In the meantime your folks can test with what's on github, as that's likely going to be the final version, except that the version number will be updated to 2013a.
To be honest one holdup at this point is the hassle of jumping through all the internal security hoops to create an official release. It's an unpleasant process and I dread having to do it. There is some benefit to not being hasty, I suppose.
****
This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html.
<<On Fri, 1 Mar 2013 09:32:37 -0500, Andrew Paprocki <andrew@ishiboo.com> said:
We have a production process based around IANA releases. This process can not depend on github snapshots. We need lead time to deploy a real IANA release to thousands of boxes in a safe manner. We can do testing using github, but that doesn't remove the need to get a regularly scheduled (as in "everyone knew about the Chile changes weeks ago") update at least a week in advance.
I think you and several other people on this list are being a bit too demanding of people who do this work without compensation in their spare time. If your process requires an "official" release, then you need to fix your process, because the official release process is not ordered around your scheduling demands. -GAWollman
On Mar 1, 2013, at 2:05 PM, Garrett Wollman wrote:
<<On Fri, 1 Mar 2013 09:32:37 -0500, Andrew Paprocki <andrew@ishiboo.com> said:
We have a production process based around IANA releases. This process can not depend on github snapshots. We need lead time to deploy a real IANA release to thousands of boxes in a safe manner. We can do testing using github, but that doesn't remove the need to get a regularly scheduled (as in "everyone knew about the Chile changes weeks ago") update at least a week in advance.
I think you and several other people on this list are being a bit too demanding of people who do this work without compensation in their spare time. If your process requires an "official" release, then you need to fix your process, because the official release process is not ordered around your scheduling demands.
The other point is that governments announce TZ changes with anywhere from a year or two lead time, to negative lead time. A day or two is quite common. So, realistically, timezone database changes, whether "official" or prereleases, will often appear after the fact. Such things are the fault of the respective governments, not of the TZ workers. paul
All, Believe me I appreciate all of the work done on this. However, my appreciation of the work and effort does not change the legal ramifications. Nor does it lessen the attention by the plant manager regional directors, production VPs, the CEO and the board. I have tried to explain the process to them and illustrate that ultimate responsibility lies with the Chilean government, However they all get glassy eyed, when I start talking International standards. My true frustration is with the Chilean Ministry of Energy and the Chilean government as a whole (I love the country and have enjoyed all of my trips there). I have expressed and requested that my company express our displeasure with how this process works. Thanks, ========================================================================= Richard Gombert Senior Technical Specialist RDE & Q - IT - Global Manufacturing D/450D 330.796.4036 GTN: 447-4036 Mailing address: PO Box 3531 (200 Innovation Way) Akron, OH 44309-3531 Shipping address: Goodyear Tire & Rubber Co. Receiving D/530A, Bldg. 72 Attn: Richard Gombert, D/450D 1376 Tech Way Drive Akron, Ohio 44306 Contains Confidential and/or Proprietary Information. May Not Be Copied or Disseminated Without Express Consent of The Goodyear Tire & Rubber Company ========================================================================= From: <Paul_Koning@dell.com> To: <wollman@csail.mit.edu>, Cc: tz@iana.org Date: 03/01/2013 02:43 PM Subject: Re: [tz] [PATCH] Updates for Chile 2013 Sent by: tz-bounces@iana.org On Mar 1, 2013, at 2:05 PM, Garrett Wollman wrote:
<<On Fri, 1 Mar 2013 09:32:37 -0500, Andrew Paprocki <andrew@ishiboo.com> said:
We have a production process based around IANA releases. This process can not depend on github snapshots. We need lead time to deploy a real IANA release to thousands of boxes in a safe manner. We can do testing using github, but that doesn't remove the need to get a regularly scheduled (as in "everyone knew about the Chile changes weeks ago") update at least a week in advance.
I think you and several other people on this list are being a bit too demanding of people who do this work without compensation in their spare time. If your process requires an "official" release, then you need to fix your process, because the official release process is not ordered around your scheduling demands.
The other point is that governments announce TZ changes with anywhere from a year or two lead time, to negative lead time. A day or two is quite common. So, realistically, timezone database changes, whether "official" or prereleases, will often appear after the fact. Such things are the fault of the respective governments, not of the TZ workers. paul
To paraphrase IT project choices: they can have timely releases or official releases - pick one! On 2013-03-04 06:38, richard_gombert@goodyear.com wrote:
All,
Believe me I appreciate all of the work done on this.
However, my appreciation of the work and effort does not change the legal ramifications. Nor does it lessen the attention by the plant manager regional directors, production VPs, the CEO and the board. I have tried to explain the process to them and illustrate that ultimate responsibility lies with the Chilean government, However they all get glassy eyed, when I start talking International standards.
My true frustration is with the Chilean Ministry of Energy and the Chilean government as a whole (I love the country and have enjoyed all of my trips there). I have expressed and requested that my company express our displeasure with how this process works.
Thanks,
=========================================================================
Richard Gombert
Senior Technical Specialist
RDE & Q - IT - Global Manufacturing D/450D
330.796.4036
GTN: 447-4036
*Mailing address:*
PO Box 3531 (200 Innovation Way)
Akron, OH 44309-3531
*Shipping address: *
Goodyear Tire & Rubber Co.
Receiving D/530A, Bldg. 72
Attn: Richard Gombert, D/450D
1376 Tech Way Drive
Akron, Ohio 44306
Contains Confidential and/or Proprietary Information.
May Not Be Copied or Disseminated Without Express
Consent of The Goodyear Tire & Rubber Company
=========================================================================
From: <Paul_Koning@dell.com> To: <wollman@csail.mit.edu>, Cc: tz@iana.org Date: 03/01/2013 02:43 PM Subject: Re: [tz] [PATCH] Updates for Chile 2013 Sent by: tz-bounces@iana.org
--------------------------------------------------------------------------------
On Mar 1, 2013, at 2:05 PM, Garrett Wollman wrote:
<<On Fri, 1 Mar 2013 09:32:37 -0500, Andrew Paprocki <andrew@ishiboo.com> said:
We have a production process based around IANA releases. This process can not depend on github snapshots. We need lead time to deploy a real IANA release to thousands of boxes in a safe manner. We can do testing using github, but that doesn't remove the need to get a regularly scheduled (as in "everyone knew about the Chile changes weeks ago") update at least a week in advance.
I think you and several other people on this list are being a bit too demanding of people who do this work without compensation in their spare time. If your process requires an "official" release, then you need to fix your process, because the official release process is not ordered around your scheduling demands.
The other point is that governments announce TZ changes with anywhere from a year or two lead time, to negative lead time. A day or two is quite common. So, realistically, timezone database changes, whether "official" or prereleases, will often appear after the fact. Such things are the fault of the respective governments, not of the TZ workers.
paul
On Mar 4, 2013, at 8:38 AM, <richard_gombert@goodyear.com> <richard_gombert@goodyear.com> wrote:
All,
Believe me I appreciate all of the work done on this.
However, my appreciation of the work and effort does not change the legal ramifications.
Legal ramifications? I would hope it is clear from all the documentation that comes with the tz data, but if you are thinking of legal ramifications you're entirely on your own. Just like any other open source effort, there are NO warrantees in the tz project. If you need something better than "as is, when available", you should look elsewhere. If your execs don't understand this, please show them the relevant disclaimers. paul
Paul, Yes. The Legal I was referring to is contracts with local unions. Bonuses, and merits are based on production counts. Production counts are collected from these machines. I did not write the contracts, nor is anyone from Plant Floor IT involved. As usually, we have to try and live up to what our lawyers promise. Thanks, ========================================================================= Richard Gombert Senior Technical Specialist RDE & Q - IT - Global Manufacturing D/450D 330.796.4036 GTN: 447-4036 Mailing address: PO Box 3531 (200 Innovation Way) Akron, OH 44309-3531 Shipping address: Goodyear Tire & Rubber Co. Receiving D/530A, Bldg. 72 Attn: Richard Gombert, D/450D 1376 Tech Way Drive Akron, Ohio 44306 Contains Confidential and/or Proprietary Information. May Not Be Copied or Disseminated Without Express Consent of The Goodyear Tire & Rubber Company ========================================================================= From: <Paul_Koning@Dell.com> To: <richard_gombert@goodyear.com>, Cc: <tz@iana.org>, <wollman@csail.mit.edu> Date: 03/04/2013 10:34 AM Subject: Re: [tz] [PATCH] Updates for Chile 2013 On Mar 4, 2013, at 8:38 AM, <richard_gombert@goodyear.com> <richard_gombert@goodyear.com> wrote:
All,
Believe me I appreciate all of the work done on this.
However, my appreciation of the work and effort does not change the legal ramifications.
Legal ramifications? I would hope it is clear from all the documentation that comes with the tz data, but if you are thinking of legal ramifications you're entirely on your own. Just like any other open source effort, there are NO warrantees in the tz project. If you need something better than "as is, when available", you should look elsewhere. If your execs don't understand this, please show them the relevant disclaimers. paul
On 04/03/13 17:01, richard_gombert@goodyear.com wrote:
Paul,
Yes.
The Legal I was referring to is contracts with local unions. Bonuses, and merits are based on production counts. Production counts are collected from these machines.
I did not write the contracts, nor is anyone from Plant Floor IT involved. As usually, we have to try and live up to what our lawyers promise.
Thanks, Your best bet is to keep an eye on this list, and as soon as someone notices a change, call your bosses and say "San Seriffe government has published today, stating DST will begin in two days, should we update all machines to rely on that, or we better wait a few days for an upstream release?".
That said, production counts should not be based on whether the timezone definitions are right...
It sure would be nice if we could always ship zoneinfo db updates in good time for orderly deployment, but so far in my career, I've found ways to partition the apps that urgently need accurate daylight savings rules (often in the region of billing or accounts) from those which are disruptive to update (in my specialty, infrastructure servers like firewalls, routers, DNS, email, and the like). The latter can often disagree with the former, as long as they agree with each other. E.g. Email spam blockers that insist on strong coherence among all the Received headers' timestamps are too fragile. And for another example, KDCs must be updated in pretty good unison, with only an hour slop among them, but clients using Kerberos auth must tolerate a couple of hours skew between the KDC clock and their own, as long as each is marching monotonically forward in coarse agreement. Late updates are reprehensible, but alas, we can only do so much better than the legislatures. Can you meet your window by processing the update from github, or are you dependent on a vendor who cannot or will not? I've met employers' demands for validation and review of zoneinfo db updates by ogling, and offering to others, diff(1) output on the output of zdump(1) against the old and new databases.
Robert Elz <kre@munnari.OZ.AU> writes:
Date: Wed, 20 Feb 2013 22:55:04 +0100 From: Petr Machata <pmachata@redhat.com> Message-ID: <m2ehgaljwl.fsf@redhat.com>
| I decided to apply the transition dates to single years only--the DST | policy is reevaluated every year anyway.
I think that's a mistake - you're guaranteeing that the data is going to be wrong, rather than simply making it likely.
I'd suggest that the data be changed as ...
--- southamerica.was 2012-07-25 21:13:46.000000000 +0700 +++ southamerica 2013-02-21 07:37:16.000000000 +0700 @@ -1277,10 +1277,8 @@ Rule Chile 2010 only - Apr Sun>=1 3:00u 0 - Rule Chile 2011 only - May Sun>=2 3:00u 0 - Rule Chile 2011 only - Aug Sun>=16 4:00u 1:00 S -Rule Chile 2012 only - Apr Sun>=23 3:00u 0 - -Rule Chile 2012 only - Sep Sun>=2 4:00u 1:00 S -Rule Chile 2013 max - Mar Sun>=9 3:00u 0 - -Rule Chile 2013 max - Oct Sun>=9 4:00u 1:00 S +Rule Chile 2012 max - Apr Sun>=23 3:00u 0 - +Rule Chile 2012 max - Sep Sun>=2 4:00u 1:00 S # IATA SSIM anomalies: (1992-02) says 1992-03-14; # (1996-09) says 1998-03-08. Ignore these. # Zone NAME GMTOFF RULES FORMAT [UNTIL]
That is, it turns out that the rules we inserted for 2012 apply for 2013 as well (except we were conservative last year, and assumed the change then was just a one year thing, and put the older dates back for 2013).
So, the patch above just assumes that the 2012/2013 strategy will continue forwards, which it might ... it is also possible that it won't, and we will need to change it again next year (or even again later this year) but some kind of reasonable guess is better than simply assuming that summer time is going to start next September, and then never end.
This makes sense, I didn't notice that the 2012 rule actually applies. Thanks, PM
This makes sense, I didn’t notice that the 2012 rule actually applies.
I also agree with extending the 2012 rule indefinitely. Deborah On Feb 21, 2013, at 4:12 AM, Petr Machata <pmachata@redhat.com> wrote:
Robert Elz <kre@munnari.OZ.AU> writes:
Date: Wed, 20 Feb 2013 22:55:04 +0100 From: Petr Machata <pmachata@redhat.com> Message-ID: <m2ehgaljwl.fsf@redhat.com>
| I decided to apply the transition dates to single years only--the DST | policy is reevaluated every year anyway.
I think that's a mistake - you're guaranteeing that the data is going to be wrong, rather than simply making it likely.
I'd suggest that the data be changed as ...
--- southamerica.was 2012-07-25 21:13:46.000000000 +0700 +++ southamerica 2013-02-21 07:37:16.000000000 +0700 @@ -1277,10 +1277,8 @@ Rule Chile 2010 only - Apr Sun>=1 3:00u 0 - Rule Chile 2011 only - May Sun>=2 3:00u 0 - Rule Chile 2011 only - Aug Sun>=16 4:00u 1:00 S -Rule Chile 2012 only - Apr Sun>=23 3:00u 0 - -Rule Chile 2012 only - Sep Sun>=2 4:00u 1:00 S -Rule Chile 2013 max - Mar Sun>=9 3:00u 0 - -Rule Chile 2013 max - Oct Sun>=9 4:00u 1:00 S +Rule Chile 2012 max - Apr Sun>=23 3:00u 0 - +Rule Chile 2012 max - Sep Sun>=2 4:00u 1:00 S # IATA SSIM anomalies: (1992-02) says 1992-03-14; # (1996-09) says 1998-03-08. Ignore these. # Zone NAME GMTOFF RULES FORMAT [UNTIL]
That is, it turns out that the rules we inserted for 2012 apply for 2013 as well (except we were conservative last year, and assumed the change then was just a one year thing, and put the older dates back for 2013).
So, the patch above just assumes that the 2012/2013 strategy will continue forwards, which it might ... it is also possible that it won't, and we will need to change it again next year (or even again later this year) but some kind of reasonable guess is better than simply assuming that summer time is going to start next September, and then never end.
This makes sense, I didn't notice that the 2012 rule actually applies.
Thanks, PM
participants (13)
-
Andrew Paprocki -
Andy Heninger -
Bennett Todd -
Brian Inglis -
Deborah Goldsmith -
Garrett Wollman -
Paul Eggert -
Paul_Koning＠Dell.com -
Petr Machata -
richard_gombert＠goodyear.com -
Robert Elz -
Wallace, Malcolm -
Ángel González