[tz] UTC calculation for March 12, 3001 [IANA #1143241], [PR 9419866]

[Lasher, Beth]

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 at 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 at siemens.com>
Cc: Time Zone Mailing List <tz at 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.