Results are sometimes off by one day when setting time in JST but calling from a different timezone

[Robb-S]

My use case is that I would like to set a specific time in JST, but the computer might be located in a different timezone. (I simulate this during testing by using the "Change Time Zone" feature in Windows.)

When I do this, sometimes the results are off by one day. Furthermore, the test results seem to be different depending on what time of day it is when I run the test.

All tests were run on the text string "next wednesday 1:30am jst" during the week of January 16. The city/timezone in parentheses was set using "Change Time Zone".

Running tests at 1pm (JST) produced these results:
(Auckland) Wed Jan 24 2024 05:30:00 GMT+1300 (New Zealand Daylight Time) / correct
(Amsterdam) Wed Jan 24 2024 17:30:00 GMT+0100 (Central European Standard Time) / one day late
(Asuncion) Wed Jan 24 2024 13:30:00 GMT-0300 (Paraguay Summer Time) / one day late
(EST) Mon Jan 22 2024 11:30:00 GMT-0500 (Eastern Standard Time) / one day early

Running tests at 7pm (JST) produced these results:
(Auckland) Tue Jan 23 2024 05:30:00 GMT+1300 (New Zealand Daylight Time) / one day early
(Amsterdam) Tue Jan 23 2024 17:30:00 GMT+0100 (Central European Standard Time) / correct
(Asuncion) Wed Jan 24 2024 13:30:00 GMT-0300 (Paraguay Summer Time) / one day late
(EST) Tue Jan 23 2024 11:30:00 GMT-0500 (Eastern Standard Time) / correct

This type of result seems to only occur when using phrases like "next wednesday" rather than specifying the exact date.

[vividn]

This bug is reproducible without changing computer timezones like this:

const chrono = require("chrono-node")
const now = new Date("2024-02-21T10:00:00+1300") // New Zealand Time
const parsed = chrono.parseDate("yesterday 18:00", { instant: now.valueOf(), timezone: 780 }) // Can also use "NZDT" for timezone, same results
const yesterday = parsed.toLocaleString("nz", {timeZone: "Pacific/Auckland"})
console.log(yesterday) // 2/19/2024, 6:00:00 PM     // Expected: 2/20/2024, 6:00:00 PM

[ivan-bialotski-sm]

+1

[wanasit]

Hello. I'm sorry for my slow reply.

I have recently tested the scenario that @vividn described (fdcfde0), and the issue should have already been fixed.

[wanasit]

Sorry. I made a mistake.

The test will still fail we are testing in the timezone that sees the reference date as the day before (e.g. in UTC "2024-02-21T10:00:00+1300" is "2024-02-20", thus yesterday is 19).

[jasonayre]

also been running into this, but from what I'm seeing, (hopefully useful context): one of the following things is broken, but the other works; until they switch expected outcomes completely:

1. relative times
   [tomorrow at 9pm, today at 9pm, yesterday at 9pm] (these will return the correct clock time but not date (it will be 24 hours off), if broken

2. day of week date times
   [wednesday at 9pm, thursday at 9pm],
   also return the correct clock time, but not date (it will be 24 hours off), if broken

When one works, the other is broken.

Then at a particular time, which seems to be based on system clock TZ (my expected results started inverting at 6pm MDT, which would be utc midnight for me), the working and broken one flip their expected results (the first starts working the second breaks)