Incorrect timezone parsing for dates in the far future

[dhassaine]

I've noticed dates in London timezone are being parsed differently between '2022-04-22T15:00:00' and '2038-04-22T15:00:00'.

LocalDateTime.parse(
'2022-04-22T15:00:00',
DateTimeFormatter.ISO_LOCAL_DATE_TIME
)
.atZone(ZoneId.of('Europe/London'))
.format(DateTimeFormatter.ISO_INSTANT)
=> '2022-04-22T14:00:00Z' (correct)

LocalDateTime.parse(
'2038-04-22T15:00:00',
DateTimeFormatter.ISO_LOCAL_DATE_TIME
)
.atZone(ZoneId.of('Europe/London'))
.format(DateTimeFormatter.ISO_INSTANT)
=> '2038-04-22T15:00:00Z' (incorrect?)

Is this a bug? JS Date and other apps like Google Calendar parse '2038-04-22T15:00:00' (London timezone) to '2038-04-22T14:00:00Z' which is different from js-joda.

[dhassaine]

The codebase is possibly running into this problem: https://en.wikipedia.org/wiki/Year_2038_problem

[pithu]

The codebase is possibly running into this problem: https://en.wikipedia.org/wiki/Year_2038_problem

No, because javascript using the number format (float) and not integer.

Might be an issue with the dst tzdb data, i will check later. latest js-joda is using 2022e, latest tzdb is 2022f. BTW: what version of js-joda you are using ? Do you know which tzdb data version google calender is using ?

[dhassaine]

@pithu hi thanks for getting back to me. I'm using the following versions:
"@js-joda/core": "5.4.2"
"@js-joda/timezone": "2.15.0"

I'm not sure how Google calendar parses it's dates.

I know Javascript's inbuilt Intl.DateTimeFormat works as expected. I wrote the following function that I'm using in the interim to deal with this issue:

/**
 * Converts an ISO formatted date time string into specified timezone
 * @param dateTime - e.g. "2022-04-22T14:00:00Z"
 * @param ianaTimezone - e.g. "Europe/London"
 * @returns ISO formatted date time string
 */
export function UTCToLocalDateTime(
  dateTime: isoDateTimeString,
  ianaTimezone: string
) {
  const utcDate = new Date(dateTime);
  const options: Intl.DateTimeFormatOptions = {
    timeZone: ianaTimezone,
    year: 'numeric',
    month: 'numeric',
    day: 'numeric',
    hour: 'numeric',
    minute: 'numeric',
    second: 'numeric',
    hour12: false
  };
  const formattedDate = new Intl.DateTimeFormat('zu', options).format(utcDate);
  const [date, time] = formattedDate.split(' ');
  return `${date}T${time}`;
}

describe(UTCToLocalDateTime, () => {
  it('returns the same date for utc timezone', () => {
    expect(UTCToLocalDateTime('2020-01-01T00:00:00Z', 'UTC')).toBe(
      '2020-01-01T00:00:00'
    );

    expect(UTCToLocalDateTime('2020-06-01T08:00:00Z', 'UTC')).toBe(
      '2020-06-01T08:00:00'
    );

    expect(UTCToLocalDateTime('2040-01-01T00:00:00Z', 'UTC')).toBe(
      '2040-01-01T00:00:00'
    );

    expect(UTCToLocalDateTime('2040-06-01T08:00:00Z', 'UTC')).toBe(
      '2040-06-01T08:00:00'
    );
  });

  it('converts utc date into specified timezone', () => {
    expect(UTCToLocalDateTime('2020-01-01T08:00:00Z', 'Europe/London')).toBe(
      '2020-01-01T08:00:00'
    );

    expect(UTCToLocalDateTime('2020-01-01T08:00:00Z', 'Europe/Madrid')).toBe(
      '2020-01-01T09:00:00'
    );

    expect(UTCToLocalDateTime('2020-06-01T08:00:00Z', 'Europe/London')).toBe(
      '2020-06-01T09:00:00'
    );

    expect(UTCToLocalDateTime('2020-06-01T08:00:00Z', 'Europe/Madrid')).toBe(
      '2020-06-01T10:00:00'
    );

    expect(UTCToLocalDateTime('2040-01-01T08:00:00Z', 'Europe/London')).toBe(
      '2040-01-01T08:00:00'
    );

    expect(UTCToLocalDateTime('2040-01-01T08:00:00Z', 'Europe/Madrid')).toBe(
      '2040-01-01T09:00:00'
    );

    expect(UTCToLocalDateTime('2040-06-01T08:00:00Z', 'Europe/London')).toBe(
      '2040-06-01T09:00:00'
    );

    expect(UTCToLocalDateTime('2040-06-01T08:00:00Z', 'Europe/Madrid')).toBe(
      '2040-06-01T10:00:00'
    );
  });
});

[pithu]

Ok, in fact its a 2038 problem, we are using the unix tool zdump under the hood, to generate the timezone information. and this tool is limited to 2038.

Update:
Find some background info here -> https://unix.stackexchange.com/questions/207415/where-is-zdump-getting-all-these-time-transitions-from

[dhassaine]

@pithu thanks for the update.

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[pithu]

Should be fixed since @js-joda/timezone@2.17.2-2022g