[JS/TS] Tests fail on timezone Australia/Melbourne (should works perhaps)

In Australia/Melbourne the typescript and javascript tests have failing cases

  2603 passing (8s)
  3 failing

  1) DateTimeOffset
       DateTimeOffset.ToString('D') works:

      Expected: Monday, 01 September 2014 - Actual: Tuesday, 02 September 2014
      + expected - actual

      -Tuesday, 02 September 2014
      +Monday, 01 September 2014
      
  

  2) DateTimeOffset
       DateTimeOffset.ToString('d') works:

      Expected: 09/01/2014 - Actual: 09/02/2014
      + expected - actual

      -09/02/2014
      +09/01/2014
      
  

  3) DateTimeOffset
       DateTimeOffset.LocalDateTime works:

      Expected: 9 - Actual: 10
      + expected - actual

      -10
      +9

Hello,

This is a known issue unfortunately there is no easy fix for it.

Duplicate of #2375

One way to work around the issue, is by using VSCode dev container to work on the test as the container is configured with the right timezone. (Europe/Paris).

If you don't want/can't use dev container you can try to configure TZ=Europe/Paris before spawning the test process.

I'm not convinced that's right. I saw that issue, but it's about a test that's commented out and would legitimately be expected to fail in other timezones.

The first two tests are for testing formatting, not the behavior of local timezones. I would not expect the formatted values to change depending on the local timezone. Indeed, if I execute it in dotnet rather than in javascript, they do not fail. This indicates it could be a bug in the fable js library.
The third test does depend on local timezone and would be expected to fail in certain timezones. I think it would be reasonable to modify this test, because LocalDateTime is already tested more thoroughly in other test cases which actually take that into account.

Sorry, because of the issue title I though you were saying that the tests were failing because of the Timezone and not because their could be an issue in the implementation.

Fix DateTimeOffset.ToString using local timezone instead of stored of…

Note

The pull request was not created — a fallback review issue was created instead due to protected file changes: #4522

🤖 This is an automated response from Repo Assist.

Thanks for the detailed bug report! I've investigated the root cause and submitted a fix.

Root cause: dateToStringWithOffset in Date.ts created the offset-adjusted timestamp with new Date(date.getTime() + offset) — a plain JS Date with no kind property. The helper functions day(), month(), year(), etc. all check d.kind === DateTimeKind.Utc and fall back to local-timezone JS methods (.getDate(), .getMonth(), etc.) when kind is undefined. On a machine in a timezone ahead of UTC, the local date can be a day ahead of the UTC date, producing the wrong output.

Fix: Use the DateTime(ts, DateTimeKind.Utc) factory instead of new Date(ts). Since we've already shifted the timestamp by the stored offset to get the "wall clock" time, reading it via UTC getters gives the correct result regardless of the machine's local timezone.

PR: (will be linked once created by the workflow)

Generated by Repo Assist · ● 10.4M · ◷

To install this agentic workflow, run
gh aw add githubnext/agentics/workflows/repo-assist.md@346204513ecfa08b81566450d7d599556807389f

This was also encountered and corrected downstream (because I am also Australian 😂), it is in #5135.

See here.

Navigation Menu

Repository navigation

[JS/TS] Tests fail on timezone Australia/Melbourne (should works perhaps) #4375

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[JS/TS] Tests fail on timezone Australia/Melbourne (should works perhaps) #4375

Description

Activity

MangelMaxime commented on Mar 2, 2026

olivercoad commented on Mar 2, 2026

MangelMaxime commented on Mar 3, 2026

github-actions commented on Apr 10, 2026

shayanhabibi commented on Oct 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions