Thanks. For the year 9999 the UTC offset is still 4/5 hours? The issue I'm seeing is using software that uses Oracle that uses your time zone database. And in June 9999 we see 3 hour offset, not 4 as expected. If it is not in your time zone database then I need to look deeper for the source of the issue. -----Original Message----- From: Paul Eggert <eggert@cs.ucla.edu> Sent: Wednesday, May 22, 2019 1:07 PM To: Lasher, Beth (DI SW S&SE AM US CSE ADFM ARC) <lasher.beth@siemens.com> Cc: Time Zone Mailing List <tz@iana.org> Subject: Re: [tz] UTC calculation for March 12, 3001 [IANA #1143241], [PR 9419866] On 5/21/19 12:04 PM, Lasher, Beth wrote:

In the year 3001, Daylight Savings time is applied on Sunday March 9, 3001 as expected.

In the Gregorian calendar March 9, 3001 is expected to be a Monday. So there seem to be some sort of glitch in your calculations.

(Eastern Standard time). BUT on the following Thursday, March 12, 3001 at 3 am, it seems that another Daylight Savings Time change is applied. After March 12, 3001, the UTC time zone offset for Eastern Daylight Savings Time is 3 hours (not 4) and remains that way until the year 9999. Is this correct? What is the cause of this second time offset change?

I don't see that behavior with the current development sources. Here's the output that I get for the command "zdump -i -c3001,3002 America/New_York": TZ="America/New_York" -    -    -05    EST 3001-03-08    03    -04    EDT    1 3001-11-01    01    -05    EST If you're seeing something different for the zdump command, please let us know. If you're using some other software, you can investigate how that software is using tzdata and/or the Gregorian calendar.

Thanks. From your data I see that the UTC offset after March 12, 3001 is still 4/5 hours. And your data shows those same UTC offsets for June in the year 9999? -----Original Message----- From: Paul Goyette <paul@whooppee.com> Sent: Wednesday, May 22, 2019 1:10 PM To: Lasher, Beth (DI SW S&SE AM US CSE ADFM ARC) <lasher.beth@siemens.com> Cc: tz@iana.org Subject: Re: [tz] UTC calculation for March 12, 3001 [IANA #1143241], [PR 9419866] On Tue, 21 May 2019, Lasher, Beth wrote:

In the year 3001, Daylight Savings time is applied on Sunday March 9, 3001 as expected. (Eastern Standard time). BUT on the following Thursday, March 12, 3001 at 3 am, it seems that another Daylight Savings Time change is applied. After March 12, 3001, the UTC time zone offset for Eastern Daylight Savings Time is 3 hours (not 4) and remains that way until the year 9999. Is this correct? What is the cause of this second time offset change?

Hmmm. On my system, in the year 3001, March 8th is a Sunday, not March 9th! And with zdump I see no extra DST changes for either America/Los_Angeles or EST5EDT: # zdump -vc 2999,3002 EST5EDT EST5EDT -9223372036854775808 = NULL EST5EDT -9223372036854689408 = NULL EST5EDT Sun Mar 10 06:59:59 2999 UT = Sun Mar 10 01:59:59 2999 EST isdst=0 gmtoff=-18000 EST5EDT Sun Mar 10 07:00:00 2999 UT = Sun Mar 10 03:00:00 2999 EDT isdst=1 gmtoff=-14400 EST5EDT Sun Nov 3 05:59:59 2999 UT = Sun Nov 3 01:59:59 2999 EDT isdst=1 gmtoff=-14400 EST5EDT Sun Nov 3 06:00:00 2999 UT = Sun Nov 3 01:00:00 2999 EST isdst=0 gmtoff=-18000 EST5EDT Sun Mar 9 06:59:59 3000 UT = Sun Mar 9 01:59:59 3000 EST isdst=0 gmtoff=-18000 EST5EDT Sun Mar 9 07:00:00 3000 UT = Sun Mar 9 03:00:00 3000 EDT isdst=1 gmtoff=-14400 EST5EDT Sun Nov 2 05:59:59 3000 UT = Sun Nov 2 01:59:59 3000 EDT isdst=1 gmtoff=-14400 EST5EDT Sun Nov 2 06:00:00 3000 UT = Sun Nov 2 01:00:00 3000 EST isdst=0 gmtoff=-18000 EST5EDT Sun Mar 8 06:59:59 3001 UT = Sun Mar 8 01:59:59 3001 EST isdst=0 gmtoff=-18000 EST5EDT Sun Mar 8 07:00:00 3001 UT = Sun Mar 8 03:00:00 3001 EDT isdst=1 gmtoff=-14400 EST5EDT Sun Nov 1 05:59:59 3001 UT = Sun Nov 1 01:59:59 3001 EDT isdst=1 gmtoff=-14400 EST5EDT Sun Nov 1 06:00:00 3001 UT = Sun Nov 1 01:00:00 3001 EST isdst=0 gmtoff=-18000 EST5EDT 9223372036854689407 = NULL EST5EDT 9223372036854775807 = NULL +--------------------+--------------------------+-----------------------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org | +--------------------+--------------------------+-----------------------+

Thank you! So the source of the error is not your database, it must be in a different link in the chain. Thanks for your help! -----Original Message----- From: Paul Goyette <paul@whooppee.com> Sent: Thursday, May 23, 2019 9:35 AM To: Lasher, Beth (DI SW S&SE AM US CSE ADFM ARC) <lasher.beth@siemens.com> Cc: tz@iana.org Subject: RE: [tz] UTC calculation for March 12, 3001 [IANA #1143241], [PR 9419866] On Thu, 23 May 2019, Lasher, Beth wrote:

Thanks. From your data I see that the UTC offset after March 12, 3001 is still 4/5 hours. And your data shows those same UTC offsets for June in the year 9999?

Same offsets for year 9999 (manually re-tabbed for alignment) # zdump -ic 9998,10001 EST5EDT TZ="EST5EDT" - - -05 EST 9998-03-08 03 -04 EDT 1 9998-11-01 01 -05 EST 9999-03-14 03 -04 EDT 1 9999-11-07 01 -05 EST 10000-03-12 03 -04 EDT 1 10000-11-05 01 -05 EST # (Identical output is generated for America/New_York zone.) Changes occur only in March and November, not in June, which (for all future-from-now times) is UTC-04. +--------------------+--------------------------+-----------------------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org | +--------------------+--------------------------+-----------------------+

On Fri, 7 Jun 2019, Paul Goyette wrote:

I don't remember seeing any previous mention of this on the tz list...

It seems that Oregon lawmakers have voted to join the US West Coast movement to permanent Daylist Saving Time...

https://www.cnn.com/2019/06/07/politics/daylight-saving-time-oregon-kate-bro...

Additional references: https://olis.leg.state.or.us/liz/2019R1/Measures/Overview/SB0464 https://olis.leg.state.or.us/liz/2019R1/Measures/Overview/HB2297 +--------------------+--------------------------+-----------------------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org | +--------------------+--------------------------+-----------------------+

On 2019-06-07, at 10:15:39, Matt Johnson wrote:

Washington and California laws indeed passed, so it will be great if Oregon joins in. But everything is dependent on US bills that are still in progress. These are really the ones to watch:

https://www.congress.gov/bill/116th-congress/house-bill/1556

https://www.congress.gov/bill/116th-congress/senate-bill/670

https://www.congress.gov/bill/116th-congress/house-bill/1601 This bill allows states to observe daylight savings time year-round. (States may already choose to observe standard time year-round.)

??? Why? States may likewise choose to move one timezone eastward. Either action requires only approval by the Secretary of Transportation, not an act of Congress. What is the effect on tm_isdst? Do they care whether their documents are timestamped PDT or MST?

Also, since Nevada and parts of Idaho are also in Pacific time, a new zone entry may still be required. I haven't seen anything indicated they are interested in changing.

-- gil

On 07/06/2019 20:38, Paul Eggert wrote:

On 6/7/19 11:57 AM, Paul Gilmartin via tz wrote:

...

What is the effect on tm_isdst?  Do they care whether their documents are timestamped PDT or MST?

As far as I know these questions have not been addressed, and quite possibly they won't be addressed even if the law changes so we'll just have to do our best. If (say) California changes to permanent -07 then the longstanding tzdb tradition would be to mark it as standard time (i.e., tm_isdst = 0); presumably it would be abbreviated "MST" for compatibility with Internet RFC 5322 and the like. No matter what we put into tzdb at that point, we'd undoubtedly break something and get complaints.

It may be confusing if large parts of the west coast are on "Mountain Time" as suggested by "MST". It seems like a good excuse to follow the more recent tradition of replacing alphanumeric abbreviations with numeric ones. -- -=( Ian Abbott <abbotti@mev.co.uk> || Web: www.mev.co.uk )=- -=( MEV Ltd. is a company registered in England & Wales. )=- -=( Registered number: 02862268. Registered address: )=- -=( 15 West Park Road, Bramhall, STOCKPORT, SK7 3JZ, UK. )=-

On Mon, 10 Jun 2019 at 11:56, Arthur David Olson <arthurdavidolson@gmail.com> wrote:

In the case of the United States, time zone names are specified in legislation and are in common use, so the "invention" consideration does not apply

Indeed, I could envision something like "Pacific Coast Time" being legislated for the coastal states, as distinct from the existing PST/PDT for the inland regions, assuming they don't join in. -- Tim Parenti

On 2019-06-10 10:08, Steve Allen wrote:

On Mon 2019-06-10T11:59:38-0400 Tim Parenti hath writ:

...

Indeed, I could envision something like "Pacific Coast Time" being legislated for the coastal states, as distinct from the existing PST/PDT for the inland regions, assuming they don't join in.

If legislation is to happen it may affect other portions of 15 U.S. Code Subchapter IX

Can TZ list produce text that would serve as guidance to help legislators avoid ambiguous or incomplete specification?

I would think most important is not to word it as "permanent DST" even if that is how they market it, but a change in standard time to the MT zone to the east. Why anyone would want that, given research results about DST effects, seems less than sensible. US W coast is W of 120W, about 8:15-20 for a lot of it, so should just drop DST. I'm in an MT zone, but the Canadian Rockies are further west than the US chain, close to 120W, so we should move to PST year round, and the more westerly and northerly regions N of Vancouver Island should move to -9 as they are nearer 135W. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.