toISOString() behaviour changed in v3
See original GitHub issueconst newSchedule = '*/10 * * * *';
const tz = 'America/New_York';
const interval = CronParser.parseExpression(newSchedule, { tz });
const prev = interval.prev();
console.error({ prev, 'prev.toISOString()': prev.toISOString() });
V2 output:
{
prev: CronDate { _date: Moment<2021-01-11T06:00:00-05:00> },
'prev.toISOString()': '2021-01-11T11:00:00.000Z'
}
V3 output:
{
prev: CronDate {
_date: DateTime {
ts: 1610362800000,
_zone: [IANAZone],
loc: [Locale],
invalid: null,
weekData: [Object],
c: [Object],
o: -300,
isLuxonDateTime: true
}
},
'prev.toISOString()': '2021-01-11T06:00:00.000-05:00'
}
I can hack it to get the previous behaviour by doing prev._date._getUTC().toISOString()
, but that’s a bit of a hack. Less of a hack but a bit of a pain could be something like (new Date(prev.getTime())).toISOString();
One can argue whether the previous behaviour was right or wrong (I can argue both sides) as it is arguably odd passing in a time with timezone and ultimately getting out a date in UTC format, but I’d still like to get to the date and turn it into UTC somehow anyway.
Ways out would be to have an official way to get a luxon date out (no underscore methods) or to add a utc() or getUTC() method (unsure which name would be best), etc. Or maybe that method should return a CronDate to keep luxon hidden?
I’m wondering if this change should be documented as well.
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (3 by maintainers)
Top GitHub Comments
@lerouxb fixed this in https://github.com/harrisiirak/cron-parser/releases/tag/3.1.0
@dmitry-yudakov thanks, also a good point.
This can be possibly solved by passing the exactly the same format (defined ECMA-262 - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toString#description) to
toFormat
function and return its results instead:Or well, even a simpler solution:
Created a quick commit with changes: https://github.com/harrisiirak/cron-parser/commit/65f6f29