Daylight savings?

[robinsongz]

Is node-cron updated for daylight savings? When I put timezone America/Los_Angeles, it is still going off pre-daylight savings times.

[vwbusguy]

I have the same issue here using {scheduled: true, timezone: "America/Los_Angeles"}

[vwbusguy]

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

[thehappycoder]

Glad I checked this before using this node package :)

[ndelanou]

Same problem here with timezone 'Europe/Paris'

[vwbusguy]

It will be a problem anywhere that does DST the way this is implemented. The offset is hard-coded.

[jaclarke]

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

[vwbusguy]

The problem is here - node-cron/tz-offset#8

[Arlen22]

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.

[jaclarke]

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.
The problem is getting that timestamp into a second, minute, hour, day, month, year format for matching to the cron expression correctly in the users local time, accounting for their local offset and DST, since the getMinutes(), getHours(), etc. methods work in the systems local time, so for most servers with UTC system time they return the same as the getUTCMinutes(), getUTCHours() methods. This is where tz-offset library returning the correct offsets for DST is needed.

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.

[Arlen22]

It would definitely need to explicitly enabled because cron is used all over the server world for stuff.

[JulienStitelet]

Is moment-timezone.js too big for you as a dep ?

[korydondzila]

I recently started using node-cron for a project and I have this as my schedule

cron.schedule('5 * 0-1,5-23 * * *', job, { timezone: "America/New_York" });

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.

[JulienStitelet]

I personally changed to 'cron' package. Where timezone and DST works as expected.