Timezone offset unexpectedly different for date in 2038 between @js-joda/timezone 2.1.1 and 2.2.0

[joshden]

I'm noticing the timezone offset in @js-joda/timezone 2.2.0 is unexpectedly different as compared to 2.1.1. I am testing this with America/Chicago time zone for 2038-09-08. For 2038-09-08 with 2.1.1 is is returning offset of -5 hours. But with 2.2.0, it is unexpectedly returning an offset of -6 hours. Although it works fine for the year before of 2037-09-08. I don't see anything in tzdata 2019c that would account for this.

TypeScript Test case:

import { ZoneId, ZonedDateTime, LocalDateTime } from "@js-joda/core";
import '@js-joda/timezone'

// const zone = ZoneId.of("US/Central")
const zone = ZoneId.of("America/Chicago")

function logDateTime(dateTime: string) {
    const localDate = LocalDateTime.parse(dateTime)
    const zonedDateTime = ZonedDateTime.of(localDate, zone)
    console.log(dateTime, zonedDateTime.offset())
}

logDateTime('2037-09-08T12:34')
logDateTime('2038-09-08T12:34')

In both cases, using @js-joda/core@2.0.0.

@js-joda/timezone 2.1.1:

2037-09-08T12:34 ZoneOffset {
  _totalSeconds: -18000,
  _rules: Fixed { _offset: [Circular] },
  _id: '-05:00' }
2038-09-08T12:34 ZoneOffset {
  _totalSeconds: -18000,
  _rules: Fixed { _offset: [Circular] },
  _id: '-05:00' }

@js-joda/timezone 2.2.0:

2037-09-08T12:34 ZoneOffset {
  _totalSeconds: -18000,
  _rules: Fixed { _offset: [Circular] },
  _id: '-05:00' }
2038-09-08T12:34 ZoneOffset {
  _totalSeconds: -21600,
  _rules: Fixed { _offset: [Circular] },
  _id: '-06:00' }

Is this expected for 2037-09-08 to be offset -5 hours and 2038-09-08 to be offset -6 hours? In both cases it should be on daylight saving time, as far as I know.

[pithu]

Could you compare this with moment timezone and or java.time ?

[joshden]

@pithu, Yes, I do see this same behavior with moment-timezone where starting in 0.5.26, it doesn't apply daylight saving time to years after 2037. This corresponds with tzdata 2019b which references changes for years after 2037. So I assume this is expected with the latest tzdata and this issue can be closed. Thank you.

Here's my test script for moment-timezone:

import moment from 'moment-timezone'

function logDateTime(dateTime: string) {
    console.log(moment.tz(dateTime, 'America/Chicago').format())
}

logDateTime('2037-09-08T12:34')
logDateTime('2038-09-08T12:34')

With moment-timezone 0.5.25 (tzdata 2019a)

2037-09-08T12:34:00-05:00
2038-09-08T12:34:00-05:00

With moment-timezone 0.5.26 (tzdata 2019b)

2037-09-08T12:34:00-05:00
2038-09-08T12:34:00-06:00

[joshden]

After looking at this more, I'm not sure this should be the expected behavior with tzdata 2019b. Perhaps someone more knowledgeable on this could take a look. I'm reopening this for now.

Furthermore, with Java 8u231 updated with the latest tzdata 2019c, I see that is has a different behavior than the latest js-joda and moment-timezone. It is behaving how the older versions of js-joda and moment-timezone behaved by calculating daylight saving time for 2038 the same as in 2037.

Java 8u231 updated using TZUpdater with tzdata 2019c:

package com.joshden;

import java.time.LocalDateTime;
import java.time.ZoneId;
import java.time.ZonedDateTime;
import java.time.zone.ZoneRulesProvider;

public class TimezoneStuff {
	private static ZoneId zoneId = ZoneId.of("America/Chicago");

	private static void logDateTime(String dateTime) {
		LocalDateTime localDate = LocalDateTime.parse(dateTime);
		ZonedDateTime zonedDateTime = ZonedDateTime.of(localDate, TimezoneStuff.zoneId);
		System.out.println(zonedDateTime.toString());
	}
	
	public static void main(String[] args) {
		TimezoneStuff.logDateTime("2037-09-08T12:34");
		TimezoneStuff.logDateTime("2038-09-08T12:34");
		System.out.println(ZoneRulesProvider.getVersions("America/Chicago").keySet());
	}
}

And this is the output:

2037-09-08T12:34-05:00[America/Chicago]
2038-09-08T12:34-05:00[America/Chicago]
[2019c]

[pithu]

Looks like an issue with tz data in moment-timezone, if i got you right. Can you report the problem there. @js-joda/timezone is simply using a copy of the moment-timezone data.

[joshden]

Thank @pithu. I didn't realize the tz data comes from moment-timezone. I added a comment to an existing issue for this moment/moment-timezone#768. I'll go ahead and close this again.