You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, the cron jobs are checked against the local time.
When constructing a Schedule an optional timezone parameter could be used. parseCronExpression would then get a second parameter timezone which is passed to the Schedule constructor.
For ease of use, it would be great if time zone names would be supported, but we would need to include and maintain a database of timezones. Also time zone offsets are not static but change over time and throughout the year. Maybe the timezone parameter should be a function utcOffset that returns the desired utc offset. One could then use other libraries such as moment-timezone to get the desired offset and cron-schedule bundle size would not increased (or use a peer dependency?). We also need to consider what happens when utcOffset returns diifferent offsets in subsequent calls (which might be realistic due to summer time / DST).
The text was updated successfully, but these errors were encountered:
Daylight Saving Time and other time changes
Local time changes of less than three hours, such as those caused
by the Daylight Saving Time changes, are handled in a special
way. This only applies to jobs that run at a specific time and
jobs that run with a granularity greater than one hour. Jobs
that run more frequently are scheduled normally.
If time was adjusted one hour forward, those jobs that would have
run in the interval that has been skipped will be run
immediately. Conversely, if time was adjusted backward, running
the same job twice is avoided.
Time changes of more than 3 hours are considered to be
corrections to the clock or the timezone, and the new time is
used immediately.
It is possible to use different time zones for crontables. See crontab(5) for more information.
For handling time zones, we can checkout the following library. Ideally it would be an optional peer dependency or not be part of the main entrypoint to keep bundle size low. https://github.com/date-fns/tz
At the moment, the cron jobs are checked against the local time.
When constructing a
Schedule
an optional timezone parameter could be used.parseCronExpression
would then get a second parametertimezone
which is passed to theSchedule
constructor.For ease of use, it would be great if time zone names would be supported, but we would need to include and maintain a database of timezones. Also time zone offsets are not static but change over time and throughout the year. Maybe the
timezone
parameter should be a functionutcOffset
that returns the desired utc offset. One could then use other libraries such asmoment-timezone
to get the desired offset andcron-schedule
bundle size would not increased (or use a peer dependency?). We also need to consider what happens whenutcOffset
returns diifferent offsets in subsequent calls (which might be realistic due to summer time / DST).The text was updated successfully, but these errors were encountered: