great job.

[meadlai]

but any detail usage?

[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)