[dqv]

You store the time you want to see on the clock tower and the timezone where the clock tower is. Every hour you do the following pseudocode:

    if utc_now().to_timzone(my_timezone) >= "9AM":
        sign = "open"

I know you didn't mean this, but it was a problem I thought about: How does one make sure the local clock tower actually changes in cadence with DST? You can't, so I guess you could use open vz with a camera to have your open sign be based on what time is actually seen on the tower.

I know it's just an example, but I say in jest, don't use cron jobs to change your closed sign to open! If you can't make it to your shop, people will be waiting around all day for you to unlock the door. Very unhappy customers.

[remram]

This is just duplicating the code already in cron. Of course you can make cron simpler by running your script every hour, and making the script more complex. You're just pushing the complexity to user-authored, non-reviewed, non-tested code. What is the advantage?

[dqv]

The first advantage is that you can dynamically check what your actual open hours are rather than having them statically configured (e.g. a web service to check for holidays). Open hours are never actually static. (Unless maybe cron does holidays?)

The second advantage is that you can check in multiple timezones especially if the server itself is in DST. Does cron itself let you set the timezone for each individual check? Or does it only run in one timezone? As far as I can tell, it only lets you use one timezone.

[remram]

You can still run whatever business logic from cron to decide whether you took the day off or you have the resources to open. Offloading the timezone logic to cron still makes sense, since running tasks at the right time is exactly what it's for.

[dqv]

It's really about trading off something I understand fairly well (a script I wrote) and something I have questions about. Since it's not a particularly important problem and I'm more likely to make errors in cron, I'd rather have everything visible in a self-contained script.

For something important, I would look at it completely differently by testing it:

- What happens if I have a scheduled cronjob running every day at a certain time, but I want to override it for one specific day and have that job run later? (e.g. how is it accomplished so that I can maintain the default behavior while overriding and opening later on specific days)

- How can I make different commands run in different timezones? (as it stands now I find conflicting information about this)

- What happens if my machine lost power when the job needed to run? (it looks like it just never runs the script)

- Can I input a specific time and test if cron will set open for that specific time? (this doesn't seem possible)

[blibble]

some timezones go forwards/back 30 minutes with DST

and historically there have been even weirder cases

[dqv]

That’s a good point. It might make more sense to run it every minute or just have its own service if it’s that important. My use case is usually a user interacting with something that causes them to see something time specific.