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.