-
-
Notifications
You must be signed in to change notification settings - Fork 14
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
Timezone / Summer time support #8
Comments
We can add configuration options. I'll look into this asap. You can post a PR proposal here to speed up things. |
@xpepermint Sorry for bothering you again. I did use a function of It would be great if you could take a look at the PR and publish a new version if you are fine with it. |
I promise I'll do my best to jump on this asap. I'm sorry you have to wait ... |
Unfortunately, I realized that your |
I refactored the code and replaced LaterJS with CronParser. Timezone can now be added easily but I wonder, do we really need that since this year we've changed our clocks for the last time (at least in Europe). |
Also, don't forget that you can have dates with timezone in the database and it will work. Any ISO 8601 is a valid date formate. Good practice, however, is to always use UTC when storing to DB. |
@xpepermint Thank you for looking at this. I would be totally fine with storing the date in UTC to the database. We changed our clocks for the last time? I must somehow missed this. As far as I know it has just been decided to do something about it with the current target for last change in 2021. |
@xpepermint I did add a new proposal (#10) to implement this feature. |
OK ... moving to the PR. |
Hi @xpepermint ,
As far as I can observe the library always works with UTC timestamps in the sleepUntil and interval field.
Is it possible to configure the library at the current state to react to summer time changes?
If not here is my idea:
I can see that the library uses moment.
In my code I use moment with the timezone extension. (moment-timezone)
I suppose with changing the imports from
import moment from 'moment';
toimport moment from 'moment-timezone';
and adding a default timezonemoment.tz.setDefault('Europe/Zurich');
the behaviour could be altered.Of course this would need a new option in the constructor. e.g.
new MongoCron({..., timezon: 'Europe/Zurich'})
I didn't test it and have not looked deep into the code.
What do you think?
Thanks,
Daniel
The text was updated successfully, but these errors were encountered: