jkbrzt / rrule

JavaScript library for working with recurrence rules for calendar dates as defined in the iCalendar RFC and more.
https://jkbrzt.github.io/rrule
Other
3.27k stars 507 forks source link

fix rezonedDate without luxon (commit: cf76af3) #547

Closed db82407 closed 1 year ago

db82407 commented 2 years ago

fixes https://github.com/jakubroztocil/rrule/issues/523

The problem was introduced in https://github.com/jakubroztocil/rrule/pull/508 by commit: https://github.com/jakubroztocil/rrule/commit/cf76af345f02dd1122a432acb5a85a7236b99228 in src/datewithzone.ts:

const dateInLocalTZ = new Date(this.date.toLocaleString(undefined, { timeZone: localTimeZone }))

This relies on new Date() parsing the output of date.toLocaleString(), but it only recognizes month/day/year, i.e. US date format. As the first parameter of date.toLocaleString() is undefined, the output will be in the host's locale. As I'm in London, that is en-GB which formats the date as day/month/year which causes new Date() to return Invalid Date.

The solution is to explicitly specify the en-US locale instead of undefined.


Thanks for contributing to rrule!

To submit a pull request, please verify that you have done the following:

milo- commented 1 year ago

@jakubroztocil would it be possible to get this released 🙏 Thanks!

emrysal commented 1 year ago

Would love to see this get merged too 👍

michaelKaefer commented 1 year ago

This fix works for me too, hope it get's merged.

freddidierRTE commented 1 year ago

We need this correction too , it would be great to get it released :smiley:

Vankata-Petrov commented 1 year ago

I would appreciate if this one gets merged. Is there anything that can be done in order to speed up the merge and the release?

BartoszJarocki commented 1 year ago

@jakubroztocil is there anything I can help with to get that fix merged? 🙏

aDedel commented 1 year ago

@jakubroztocil Can we merge this pull request asap please :pray: Thanks !

hugodichon commented 1 year ago

Please @jakubroztocil if you can review it and merge. This is realy a bummer for us. It would be a pity to have to fork just for that...

davidgoli commented 1 year ago

Why en-US? Will there be any side effects from this choice?

davidgoli commented 1 year ago

Thanks for contributing this PR!

I'm seeing the test that was introduced failing, even with the code change, so that will need to be fixed before this PR can be merged. I'd like to see a failing test introduced illustrating the problem, then changes that fix that failing test (without changing the behavior of other tests).

Additionally, I'm not convinced this is the right fix:

If the application doesn't provide a locales argument, or the runtime doesn't have a locale that matches the request, then the runtime's default locale is used.

(https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl#locale_identification_and_negotiation)

The undefined argument should use the default system locale. It might be necessary to provide an argument for specifying the locale, but it probably should not be hardcoded in this way.

db82407 commented 1 year ago

I'm seeing the test that was introduced failing, even with the code change, so that will need to be fixed before this PR can be merged. I'd like to see a failing test introduced illustrating the problem, then changes that fix that failing test (without changing the behavior of other tests).

Please can you tell me where you see it failing?

If I remove the fix and just include the new test, I see

$ LANG=en_US yarn test
381 passing (1s)
  9 pending

and

$ LANG=en_GB yarn test
380 passing (1s)
  9 pending
  1 failing

  1) RRule
       testBetweenWithTZ [every week on Tuesday] [DTSTART;TZID=Europe/London:20220613T090000
RRULE:FREQ=WEEKLY;BYDAY=TU]:
     TypeError: Cannot read properties of null (reading 'split')
      at Object.inspectDate [as Date] (node_modules/loupe/loupe.js:384:36)

That error is caused because the value being split is Invalid Date.

Adding the fix, the tests work in both locales for me.

davidgoli commented 1 year ago

Looks like there are some Prettier errors...

db82407 commented 1 year ago

Looks like there are some Prettier errors...

Sorry, now fixed. Please approve workflow.

db82407 commented 1 year ago

I've fixed the expectedDates for the failing test. I also found that expectedDate() was using similar logic to rezonedDate(), so I extracted a common dateInTimeZone() method.

davidgoli commented 1 year ago

We could probably also use some new workflows in .github/workflows/nodejs.yml to run in a few various locales, using the LANG= env variable...

db82407 commented 1 year ago

Rather than adding new workflows, I've just specified LANG corresponding to the specified TZ. I've enabled workflows on my fork and the updated test matrix runs successfully.

db82407 commented 1 year ago

Looks great & works on my machine (and in CI!). Thanks for your contribution!

Glad to help.