New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Daylight savings? #157
Comments
I have the same issue here using |
The timezone offset is hard-coded in the supporting library, so it doesn't support DST: https://github.com/node-cron/tz-offset/blob/master/generated/offsets.json |
Glad I checked this before using this node package :) |
Same problem here with timezone 'Europe/Paris' |
It will be a problem anywhere that does DST the way this is implemented. The offset is hard-coded. |
Instead of a hard-coded list of offsets, there's the way Luxon handles it using the Intl.DateTimeFormat api (https://moment.github.io/luxon/docs/manual/zones.html#iana-support). However this would mean only supporting modern browsers / node 8+ without a polyfill (https://moment.github.io/luxon/docs/manual/matrix.html). |
The problem is here - node-cron/tz-offset#8 |
Servers normally run UTC anyway, so the offset is just helpful. Besides, you wouldn't want the mess of making sure tasks don't duplicate on the night DST starts or ends. But maybe some one else has some examples of how it could be helpful. I guess it depends on what people use it for and it could be made optional. |
As I understand it, a js Date object doesn't really have a timezone/offset associated with it anyway, it just stores the date as a number of milliseconds since the 1st Jan 1970 epoch, so is effectively using UTC internally. I think you're right that it does depend on what the cron expression is. For something like "0 * * * *" where the task just runs every hour the offset doesn't matter, but for tasks that run for example once a day at a specific time (eg "0 9 * * *"), you probably want it to run in the users local time, eg. for a user in the America/Los_Angeles timezone, 9:00 local time should be scheduled at 17:00 UTC (or 16:00 UTC during DST) on the server. As for handling the weird missing or repeated hour when DST starts or ends, here's how its handled it in cronosjs, which handles it by adding and subtracting an hour from the date in UTC, and comparing how many hours are actually offset in local time to detect the missing/repeating hours and adjusting the date accordingly. |
It would definitely need to explicitly enabled because cron is used all over the server world for stuff. |
Is moment-timezone.js too big for you as a dep ? |
I recently started using node-cron for a project and I have this as my schedule
This should have the cron run on the 5th second of every minute from 5am to 1am in EST, which observes DST. The issue is that during DST, because node-cron doesn't observe it or have a way to enable it, the job runs from 6am to 2am. The easiest fix for me is to just have to run constantly and not during a specific range of hours, but this isn't preferred. The server runs UTC, but the time range required is tied to real world event that runs from 5am to 1am, so I think this is a specific example where DST support is needed. |
I personally changed to 'cron' package. Where timezone and DST works as expected. |
I personally just moved from 'cron' due to this issue kelektiv/node-cron#315 and ran into this issue. I'm just going to have to use the real cron. It seems like none of the cron modules for node work. |
In fairness, willtalmadge, it works about as well as most nodejs libraries do. It fit the specific use case for the person who made it and now the rest of us are trying to figure out how to workaround that implementation. Unless someone is willing to fork this code and maintain it, we're stuck with remembering to patch and release our code that depends on this every time daylight savings changes happen. |
I've submitted a pull request to the node-cron/tz-offset library that this one depends on, to handle DST changes correctly using the Alternatively, if you don't mind only having support for newer browsers/node versions, I've also published the cron library (cronosjs) that I wrote when I ran into the DST problem using this library (also because I needed to be able to get the next date the cron expression matched), which I'm happy to maintain. (As a bonus it handles some extended cron syntax and has configurable handling of the missing/repeated hours that come with DST starting/ending) |
You are right, I was overly harsh out of frustration. |
Looks like this might have been resolved with #248 in version 3.0.0. |
I was stuck with a similar issue and found a simpler workaround using dayjs, which can account for daylight savings on its own. Schedule the job thrice:
Inside the
Now the job runs from 5 am to 1 am throughout the year cuz the above |
I upgraded node-schedule to version 2.0.0 and can confirm that timezones are now working correctly (tested the timezone 'America/New_York' on AWS ECS which had a default timezone set to UTC. |
It's not working for me - now that it's entered British Summer Time all the jobs I set are happening 1 hour later than expected. I'm using node-cron version 3.0.2 |
Timezones and daylight savings work for me too. |
However, there is a memory leak when using timezone: #358 |
Is node-cron updated for daylight savings? When I put timezone America/Los_Angeles, it is still going off pre-daylight savings times.
The text was updated successfully, but these errors were encountered: