4 ms·

As the very last line mentions, "use UTC" and avoid silly DST issues like this.

midasuni 5y ago
My shop opens when the local clock tower says 9 am I want a cronjob set up to change the “closed” sigh to say “open”. How do I set that with UTC?
- PetahNZ 5y ago
  Set the cron job to run every hour in UTC, and your application logic checks if its time to open in the configured time zone.
  - kymaz 5y ago
    So the fix to using UTC for computers and crons that only care about the local time zone is to reimplement time checking? If youre just gonna run it every hour, you might as well while(1){ check time; do stuff; sleep 1 hour;} now there's one less dependency?
    - rovr138 5y ago
      It depends on that never dying.
      - kymaz 5y ago
        You also depend on cron never having a bug, and you also depend on crons working as intended, unless you also have some extra system logging your cron jobs.
  - dbaupp 5y ago
    Unfortunately there’s more … interesting time zones than UTC+/-xx:00, and more interesting transitions than moving an hour. For instance, Nepal uses UTC+05:45, and the time shifted by 15 minutes in 1986 (from UTC+05:30): https://www.timeanddate.com/time/zone/nepal/kathmandu https://www.timeanddate.com/time/zone/nepal/kathmandu That said, I think running every 15 minutes handles all currently-observed time zones.
- dzdt 5y ago
  This is a same problem in financial markets. Things like options contracts depend on a value observed say at 10am New York time on a particular date a decade in the future. If the daylight savings time schedule changes between now and then then the UTC time of the expiry of the options contract will change. The right reference isnt UTC or EST or EDT but "NY City local time" (or Tokyo or Warsaw or Mexico City or whatever is the relevant jurisidiction).
- noja 5y ago
  Open your shop at 0900 UTC
- dqv 5y ago
  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 5y ago
    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 5y ago
      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 5y ago
        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.
        5y ago
- oxfeed65261 5y ago
  First of all, you’ll need a webcam pointed at the local clock tower…
tshaddox 5y ago
And probably don't schedule anything for the last few seconds of a calendar year.
- janiscaune69 5y ago
  End of year is fine, it is around start of day / end of day when DST switches that screws up things
  - tshaddox 5y ago
    I was referring to leap seconds, which are applied at the end of the calendar in UTC, and are the only cases where UTC is not a continuous and predictable time scale. A scheduling system like cron still needs to have some mechanism to handle events that are scheduled in UTC, because particular UTC seconds can be skipped over. (And FYI, this can actually happen in other parts of the calendar year, not just the end.)
    - mdavidn 5y ago
      A leap second would be a change "less than 3 hours," so the job should still run according to the cited Debian man page. Google's NTP servers smear leap seconds over an entire day, so UTC may appear continuous despite leap seconds. https://developers.google.com/time/smear https://developers.google.com/time/smear
      - tshaddox 5y ago
        Indeed. I only meant that simply switching to UTC doesn't actually reduce the necessity for the complex handling of scheduled events this article describes. It would just make these cases occur less frequently.
dbrueck 5y ago
Would that it were so simple! For cronjobs, maybe it often is, but DST transitions are a mess to deal with in things like calendaring UIs and other places where you have to convert point-in-time values to the format consumed by normal people, and where your users can have different but legitimate expectations about how those transitions should be handled. At one company I remember helping build a scheduling UI for a linear TV broadcast channel, where you plan out the broadcast day in 24h blocks. Worked great except twice a year when, due to DST, you have either a 23h day or a 25h day, and half a dozen ways various customers expected that to be handled. The de facto solution was to have happy customers 363 days a year. :-/ Hey, but thank goodness for https://en.wikipedia.org/wiki/Uniform_Time_Act https://en.wikipedia.org/wiki/Uniform_Time_Act or it would have been even worse!
mason55 5y ago
A better answer is to use time+locale for things that are supposed to happen in the future and UTC for things that happened in the past. The reason is that things that happened in the past will have a specific moment on the arrow of time at which they happened, and UTC is as good as anything else for putting a consistent label on the arrow of time. But, for things that are going to happen in the future, you have no way of knowing if two "time labels" that right now point to the same moment on the arrow of time might have some change that causes them to point to different moments. In this case UTC removes the ambiguity about the timezone that the time is in, but it adds ambiguity about which moment in time you're really talking about. Let's say you want to schedule something for 9pm local time (UTC-3). So you schedule it for midnight UTC. Then your timezone shifts to UTC-2 and your appointment moves to 10pm. That's likely not at all what you intended. It's also why you need to pick a "master" timezone when you're sending invites to multiple timezones and let the rest of the times be derived from the "single source of truth" time.
- stefan_ 5y ago
  This heuristic obviously doesn't work. I build a factory in a strategy game. It is going to take 10h. The timezone shifts; should it take longer, shorter, the same? Obviously the same. You still need to use your brain and careful UI design. Things that a user scheduled to happen at a specific local time need to store the relevant timezone, implicitly or explicitly.

My shop opens when the local clock tower says 9 am I want a cronjob set up to change the “closed” sigh to say “open”. How do I set that with UTC?

PetahNZ 5y ago
Set the cron job to run every hour in UTC, and your application logic checks if its time to open in the configured time zone.
- kymaz 5y ago
  So the fix to using UTC for computers and crons that only care about the local time zone is to reimplement time checking? If youre just gonna run it every hour, you might as well while(1){ check time; do stuff; sleep 1 hour;} now there's one less dependency?
  - rovr138 5y ago
    It depends on that never dying.
    - kymaz 5y ago
      You also depend on cron never having a bug, and you also depend on crons working as intended, unless you also have some extra system logging your cron jobs.
- dbaupp 5y ago
  Unfortunately there’s more … interesting time zones than UTC+/-xx:00, and more interesting transitions than moving an hour. For instance, Nepal uses UTC+05:45, and the time shifted by 15 minutes in 1986 (from UTC+05:30): https://www.timeanddate.com/time/zone/nepal/kathmandu https://www.timeanddate.com/time/zone/nepal/kathmandu That said, I think running every 15 minutes handles all currently-observed time zones.
dzdt 5y ago
This is a same problem in financial markets. Things like options contracts depend on a value observed say at 10am New York time on a particular date a decade in the future. If the daylight savings time schedule changes between now and then then the UTC time of the expiry of the options contract will change. The right reference isnt UTC or EST or EDT but "NY City local time" (or Tokyo or Warsaw or Mexico City or whatever is the relevant jurisidiction).
noja 5y ago
Open your shop at 0900 UTC
dqv 5y ago
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 5y ago
  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 5y ago
    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 5y ago
      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.
      - 5y ago
oxfeed65261 5y ago
First of all, you’ll need a webcam pointed at the local clock tower…

tshaddox 5y ago

And probably don't schedule anything for the last few seconds of a calendar year.

janiscaune69 5y ago
End of year is fine, it is around start of day / end of day when DST switches that screws up things
- tshaddox 5y ago
  I was referring to leap seconds, which are applied at the end of the calendar in UTC, and are the only cases where UTC is not a continuous and predictable time scale. A scheduling system like cron still needs to have some mechanism to handle events that are scheduled in UTC, because particular UTC seconds can be skipped over. (And FYI, this can actually happen in other parts of the calendar year, not just the end.)
  - mdavidn 5y ago
    A leap second would be a change "less than 3 hours," so the job should still run according to the cited Debian man page. Google's NTP servers smear leap seconds over an entire day, so UTC may appear continuous despite leap seconds. https://developers.google.com/time/smear https://developers.google.com/time/smear
    - tshaddox 5y ago
      Indeed. I only meant that simply switching to UTC doesn't actually reduce the necessity for the complex handling of scheduled events this article describes. It would just make these cases occur less frequently.

dbrueck 5y ago

Would that it were so simple! For cronjobs, maybe it often is, but DST transitions are a mess to deal with in things like calendaring UIs and other places where you have to convert point-in-time values to the format consumed by normal people, and where your users can have different but legitimate expectations about how those transitions should be handled. At one company I remember helping build a scheduling UI for a linear TV broadcast channel, where you plan out the broadcast day in 24h blocks. Worked great except twice a year when, due to DST, you have either a 23h day or a 25h day, and half a dozen ways various customers expected that to be handled. The de facto solution was to have happy customers 363 days a year. :-/ Hey, but thank goodness for https://en.wikipedia.org/wiki/Uniform_Time_Act https://en.wikipedia.org/wiki/Uniform_Time_Act or it would have been even worse!

mason55 5y ago

A better answer is to use time+locale for things that are supposed to happen in the future and UTC for things that happened in the past. The reason is that things that happened in the past will have a specific moment on the arrow of time at which they happened, and UTC is as good as anything else for putting a consistent label on the arrow of time. But, for things that are going to happen in the future, you have no way of knowing if two "time labels" that right now point to the same moment on the arrow of time might have some change that causes them to point to different moments. In this case UTC removes the ambiguity about the timezone that the time is in, but it adds ambiguity about which moment in time you're really talking about. Let's say you want to schedule something for 9pm local time (UTC-3). So you schedule it for midnight UTC. Then your timezone shifts to UTC-2 and your appointment moves to 10pm. That's likely not at all what you intended. It's also why you need to pick a "master" timezone when you're sending invites to multiple timezones and let the rest of the times be derived from the "single source of truth" time.

stefan_ 5y ago
This heuristic obviously doesn't work. I build a factory in a strategy game. It is going to take 10h. The timezone shifts; should it take longer, shorter, the same? Obviously the same. You still need to use your brain and careful UI design. Things that a user scheduled to happen at a specific local time need to store the relevant timezone, implicitly or explicitly.