Code Monkey home page Code Monkey logo

Comments (6)

isoos avatar isoos commented on July 30, 2024

@Jayesslee: this is running only on the local clock. What is the requirement with time zone you are looking for?

from cron.

ryanheise avatar ryanheise commented on July 30, 2024

I think it would be useful to allow each schedule to optionally have a non-local timezone.

My use case is to manage different schedules for different users in their preferred timezone, but since the tasks will be scheduled all on one server, the server needs to be able to juggle different timezones. Translating the schedule into the server's timezone won't work since that will change the behaviour of schedules near midnight when transitioning in and out of daylight saving time.

from cron.

isoos avatar isoos commented on July 30, 2024

I can see that this can get super-complex easily. Do you have any suggestion how to implement this?

from cron.

ryanheise avatar ryanheise commented on July 30, 2024

I had only given a thought to the API design, which would be to add a timezone parameter to schedule() which defaults to local time.

But looking at the code, that timezone could then be propagated to an extra field in _ScheduledTask so that tick() can apply that timezone before passing the applicable DateTime into schedule.shouldRunAt(now).

There are other ways to go about it such as making it a parameter of Schedule instead, but the above seems to be the most flexible.

from cron.

isoos avatar isoos commented on July 30, 2024

I'm happy to review and merge this (esp. with at least a few test cases), but I don't have time for it right now. Are you interested?

from cron.

ryanheise avatar ryanheise commented on July 30, 2024

I'm not 100% sure on which API design would be best. Of course it's a matter of whether you want to think about a Schedule being something that is in a particular timezone, or being timezone agnostic. While the original cron itself wasn't designed with this consideration, if I take systemd timer units as inspiration, the timezone there IS actually part of the schedule string, so arguably there is some sense in making the timezone an extra field in Schedule even though it was not there in the original cron.

So for now I think I wouldn't jump into anything just yet and see if there's any feedback on the API before committing to it.

from cron.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.