Avoid 2:00 and 3:00 am cron jobs (2013)

https://www.endpointdev.com/blog/2013/04/avoid-200-and-300-am-cron-jobs/

by pera • 9 months ago

341 365 9 months ago

noir_lord3• 9 months ago

I worked at a place that had set the servers to BST not UTC and used cron jobs extensively for reporting, which caused chaos twice a year and twice a year they had to explain to the business again why it caused chaos and ask for the time to fix it.

Company went bust before it got fixed.

Just use UTC folks unless you have a really good idea why you shouldn't.

lxgr21• 9 months ago

"Our customers aren't in UTC" is often a compelling reason.

People generally expect things like usage limits to reset overnight, not at UTC midnight, and these are often implicitly tied to (the result of) batch jobs.

Financial jobs, including billing, is another big category.

latchkey19• 9 months ago

Always set the servers to UTC. Convert the time to local time for display, but store in UTC.

The reporting job should be run from a server on UTC and on UTC time. The report itself can convert to whatever is local time.

freedomben• 9 months ago

Having tried many times to use local time instead of UTC to make life simpler for myself, I really don't think it's ever a good idea.

Better to localize times for users on the client-side based on their local settings, IMHO

For quotas and usage limit resets it can be a little harder, but if it's a cron job anyway, my initial approach would be to just schedule it for a time that is close to midnight for the area your customers are in.

Kwpolska2• 9 months ago

That does not require setting the server to local time. Run the cron job every hour. Before starting the script, check the time and compare it to the last saved execution time. If the day has changed, do stuff and save the new date, else exit. This also happens to be more resilient to server downtime around midnight.

skissane7• 9 months ago

"Our customers aren't in UTC" is often a compelling reason.

This doesn’t work as soon as you become a global business… because if you tell a customer in Asia that it resets at midnight in some US timezone, what are they going to think?

Many people will accept UTC because it is the international standard. Everyone will accept “let each customer pick the timezone that works best for them”. Saying “I’m going to use a US timezone because that is easiest for our US customers” risks sending a message to your (now or future) global customers that you view them as second-class citizens.

latchkey19• 9 months ago

At Marin Software, they ran each customer on their own set of servers and set the servers to the customers defined TZ. It was an endless cronjob nightmare. Now they are also bankrupt.

Just found out some guy decided to try to restart the company. Good luck. https://x.com/Austen/status/1981904435539280324

ta12434• 9 months ago

If I want a report of what happened at a specific time I need that report at local time

I get a daily status report of various things from our 24 hour operational management team which runs at 8am UK time every day. That means last week it ran at 0700UTC and this week at 0800UTC

This is built around operational events, shift changes, etc.

I've got another system which is in operation in Sydney from 0630 to 1630 local time, this means that maintence windows which overlap with UK shift patterns depend on the week but mean the system is operating 2130-0730 UK time at some times, 2030-0630 UK at others, and 1930-0530 at others.

UTC is not "the answer". Sometimes you want things running at a UTC time, sometimes you want them running at local time.

I have a regular meeting at 10am London time on Tuesday and Thursday. That can't be stored in UTC as it varies depending on the time of the year. It has to have the timezone stored and actioned.

latchkey19• 9 months ago

You can tell the job when to run in UTC time and change that time depending on what the current DST rules are.

But if the job is set to run in UK time and the system clock jumps around because of TZ changes, it will run twice or not at all.

Having a stable zero based time that doesn't move around by external forces that you can't control is "the answer."

baq3• 9 months ago

I agree with most everything except:

If I want a report of what happened at a specific time I need that report at local time

this is hard when a particular hour can happen twice in a day right?

jedberg7• 9 months ago

Just use UTC folks unless you have a really good idea why you shouldn't.

If my whole team is based in Pacific Time, I'm gonna use something close to PT so I don't have to do hard math when reading raw logs.

If we're all US based, I still want something in the USA. The math is easier.

kjehjrktlhl3• 9 months ago

Technical debt. Please don’t.

onraglanroad3• 9 months ago

Hard math. Ah right, I think it's not till the third year of a mathematics degree that you deal with "subtracting 8"! :)

adammarples• 9 months ago

Why not just store everything utc but add a local time to the logging along with it?

joeiq• 9 months ago

`date -u` gives you current UTC time when the arithmetic trips you up.

yabones• 9 months ago

I put a little analog clock on my desk that's set to UTC time. It helps a lot with converting logs to get a quick reference.

derwiki2• 9 months ago

I do the same! I am in PDT and keep a UTC and EDT clock (most of my team is east coast)

schraitle• 9 months ago

I have a piece of paper on my desk, each side has the time zone, utc offset, and date when DST will change. Twice a year I flip over the paper.

Right now it reads "EDT, UTC-4, until: Sun, Nov 2"

Going to add a clock next to it now, that's a great idea

ZeWaka• 9 months ago

Analog clock is a great idea. I just use the Windows multiple timezone clocks feature, but I can see the usefulness of being able to glance at UTC.

gtowey• 9 months ago

I really love this idea!

walthamstow2• 9 months ago

One of the great things about living at 0 latitude is it's UTC half the year

lozf2• 9 months ago

Perhaps a shell alias for:

TZ="Etc/UTC" xclock -analog -update 1 -norender -hl grey -fg grey -bg black

(or similar) would also suffice.

1-more2• 9 months ago

Expense a Rolex GMT Master or Sky Dweller. Tell your boss I said it was necessary!

nodesocket• 9 months ago

I use UTC for all public/production servers, but for my homelab servers in my closet rack they all use local time. Makes grokking times in homelab servers much easier. The exception is database insert/update date/times which are always stored UTC.

SecondHandTofu• 9 months ago

Generally, yes but I there's a surprising amount of cases when it is important, which makes it difficult to generalise e.g. Huge amounts of the financial sector cares because of market times or regulatory reasons.

jacobsenscott• 9 months ago

Also don't use cron full stop. Build (or use an off the shelf) scheduler in your app that's more sophisticated, has access to data and client preferences, etc.

superkuh• 9 months ago

This isn't a problem with actual cron and crontab. It is a problem with the systemd-timers shim "crontab" which doesn't work the same in many corner cases and often has weird bugs.

lxgr21• 9 months ago

"Not a problem" as in these only run these cron job once per day, irrespective of DST changes making a given "hour happen twice"?

Bratmon• 9 months ago

How does actual cron handle this situation?

LegionMammal978• 9 months ago

This post is literally about an issue observed in vixie-cron (as included in some distro c. 2013), not about any systemd implementation.

nailer• 9 months ago

Exactly! The article makes the point that:

until one of them achieves cron’s level of ubiquity, we have to live with cron at least some places and sometimes

systemd could arguably be described as close to (maybe behind, maybe ahead of since it's the default for the most popular Linux distros) cron's level of ubiquity, and doesn't have this bug as far as we know.

ziml77• 9 months ago

What do you consider "actual cron"? Because the post specifically says Vixie cron, which has been the basis for most versions of cron on Linux systems.

Kwpolska2• 9 months ago

Which cron is actual cron? There are tons of implementations out there.

This post describes vixie-cron, not systemd-timers.

cuu508• 9 months ago

Apparently there are some timezones (Cuba, Egypt, Lebanon) where DST change happens at midnight, so, also watch out for that!

https://mas.to/@mpirnat/115395859892135002

latchkey19• 9 months ago

There are TZ rules that do all sorts of wild things.

noir_lord3• 9 months ago

Leading to my favourite web comic of all time.

https://www.monkeyuser.com/2018/going-global/

Monkey User is always entertaining.

wat10000• 9 months ago

Brazil not only had DST at midnight, but until 2008 they also had no standard rule for when DST would begin and end, setting the dates by decree often just a few weeks in advance.

baq3• 9 months ago

Is there any other person other than Arthur David Olson who needed an RFC written to cover their retirement?

https://www.rfc-editor.org/rfc/rfc6557.html

spogbiper• 9 months ago

https://www.timeanddate.com/time/time-zones-interesting.html

I wonder how on earth do you deal with a 30 or 45 minute offset in real life

cesarb• 9 months ago

Wait, are there timezones where the DST change doesn't happen at midnight? That's news to me.

Now this article makes sense to me; I was wondering what made 02:00 and 03:00 special, since the DST changes would be from 00:00 to 01:00 and from 00:00 to 23:00, as I'm used to since childhood here in Brazil. Perhaps some other countries change DST from 02:00 to 03:00 and vice versa?

aflag• 9 months ago

In the UK we move forward at 1am and they go backward at 2am. Doing it at midnight adds the extra complexity that now the day is different. Doing it in the early morning doesn't change the day.

My guess is that in the US they do the same but shifted by one.

dist-epoch• 9 months ago

All of Europe changes from 02:00 to 03:00

jasongill• 9 months ago

In the United States, we go from 1:59am to 3:00am in March, and from 1:59am to 1:00am in November for our time change.

maratc• 9 months ago

Most timezones change time when there's a minimal amount of people working, as these people would have to work an extra hour, and doing it at around 3am is the most reasonable from that point of view.

gadders2• 9 months ago

Also, never set jobs to run at midnight (00:00) as nobody will be able to tell what day it is. Set it to 00:01 or something.

And tbh, don't run jobs on the hour anyway. Everything kicks off then. Set stuff to run at 01:45 or 02:15 or something instead.

(None of these suggestions are time change related)

tetha2• 9 months ago

In general I try to use odd times for cronjobs. Backups starting at XX:13, analysis scripts at XX:23, data exports at XX:42 and so on. This simplifies the question of "Why does my system go whack at 23:23? Oh, wait".

kibwen• 9 months ago

With enough precision in your timestamp, you can base-10 encode arbitrary binary data and shove it in your nanos for debugging.

ksenzee• 9 months ago

This is a great tip. One of our QA engineers noticed recently that a particularly difficult-to-reproduce bug was affecting records saved at :21, which is when a particular cronjob hits. Without that extra info we’d probably still be scratching our heads over it.

gadders2• 9 months ago

That's a good idea.

ericpauley2• 9 months ago

Honestly haven’t seen 00:00 cause confusion outside of “dog ate my homework” scenarios. If you’re using 12h clock then clearly it’s a bigger issue.

ttz• 9 months ago

Alternatively, where possible set the server timezone to UTC so that no daylight savings changes will happen at all

this is the way

bobmcnamara6• 9 months ago

Use TAI

ldoughty• 9 months ago

I try to avoid crons at the top of the hour, partly because of this... but also because (in shared / serverless infrastructure) I assume a lot more people are setting their crons for 'on the hour' so there's more resource contention... I also aim for 'after 4am' where I can as well, or 'before midnight', to avoid this whole range.

sgc• 9 months ago

To incrementally improve that tactic, systemd has RandomizedDelaySec, which is a convenient way to reduce the possibility of scheduling conflicts.

tetha2• 9 months ago

I prefer to combine this with FixedRandomDelay=true. FixedRandomDelay ensures that the randomized delay is an arbitrary number up to RandomizedDelaySec, but it is deterministic per server and timer. I find this useful because this means the timer will always run at XX:12:45 on server01, always run on XX:06:23 on server02 and so on.

This combines very simple configuration, while being predictable and spreading out timers well.

layer8• 9 months ago

One trick for cron is to prepend the actual command in the crontab with something like

    sleep $(( $(od -N1 -tuC -An /dev/urandom) % 60 ))m ;

which will delay it by 0 to 59 minutes at random.

throwaway1063823• 9 months ago

bruh, just use UTC

bobmcnamara6• 9 months ago

Ugh gross. Same non monotonic time problems just not every year.

TAI4LYFE!

jedberg7• 9 months ago

I've told this story before, but it's super relevant here. When I set up all the servers for reddit, I set them all to Arizona time. Arizona does not have DST, and is only one hour off of California (where we all were) for five months, and the same as here the rest of the year.

I didn't use UTC because subtracting eight when reading raw logs is a lot harder than subtracting one.

They use UTC now, which makes sense since they have a global workforce and log reading interfaces that can automatically change timezones on display.

latchkey19• 9 months ago

Computers can do things. Build a UX to read the logs and have it automatically parse/convert the logs to show whatever is local time.

https://unix.stackexchange.com/questions/274816/how-to-conve...

jedberg7• 9 months ago

There are many solutions, but when you're actually running a site with millions of daily visitors and one person focused on ops, you do the easy thing, not the right thing, unless those happen to coincide.

ocdtrekkie• 9 months ago

The problem is a lot of times when you are looking at logs you are already very far off the happy path of things you look at often and want to invest resources into displaying well.

lxgr21• 9 months ago

Computers can do things. Build a UX [...]

That sounds like a job for a human (at least the review part), not only a computer.

mananaysiempre• 9 months ago

In my experience, the hard part is getting everybody else to do that. And then also getting them to actually include the timezone in their communication with you.

rconti• 9 months ago

I'd rather the logs be consistent, and not rely on every single person who ever looks at the system logs make sure to use the correct tool the correct way.

VintageCool• 9 months ago

Nooo... we have a bunch of metrics and logs reporting systems at my company. Some of them are in UTC, some of them display my local time, some of them display China Time, and I'm trying to collaborate with colleagues in London and Australia who get data displayed in their local times as well. When I'm working to address an incident and combing through multiple systems to try to correlate events, it's a pain in the ass having to constantly double-check which time zone this data is in.

kjehjrktlhl3• 9 months ago

This is not smart, this is just surprising to the next person who is going to maintain your ”smart” tricks. Thank god they switched to utc, that is what everyone expect.

adzm2• 9 months ago

Sounds like it was smart at the time, and then eventually outgrew the solution.

jedberg7• 9 months ago

Actually, back then, 18 years ago, most people expected your servers to be in Pacific or Eastern time, depends on where your company was headquartered, because none of us really had global technical workforces back then. We all pretty much worked in one office and used the local time zone, because often our servers were in the building with us or in a datacenter nearby.

Case in point, before reddit I was at eBay, and we kept all those servers in Pacific time, since the entire technical workforce was in Pacific time, as well as all of the servers.

Making blanket statements like that without considering the context of the time is usually not a good idea. ;)

embedding-shape• 9 months ago

If you're like 5 people, each with a list of TODOs that doesn't fit on one screen, it's pretty smart to just do something quick and good enough, then move on, revisit it in the future.

dang• 9 months ago

Can you please make your substantive points without swipes? This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html.

amaccuish• 9 months ago

I believe it was an anecdote and not a recommendation.

stronglikedan• 9 months ago

It was probably the smartest option at the time, given the context. As long as it was documented properly, no one on such a small team would have been surprised. Spend more than the 30 minutes you've spent here on HN so far, and you may learn a thing or two about what is "smart", and how that is inextricably linked to the given situation.

adzm2• 9 months ago

I didn't use UTC because subtracting eight when reading raw logs is a lot harder than subtracting one.

Also important here is that the date stays the same! Even though I've gotten used to instinctively decoding UTC, that part is still frustrating sometimes.

iamtedd2• 9 months ago

What about that one hour in the day when the date isn't the same?

aerostable_slug2• 9 months ago

I've had to try to clean up after a similar early decision and it was very painful.

Please stick with utc across the board people, someone someday may have to clean up your mess.

jedberg7• 9 months ago

Nowadays I'd agree with you, UTC is probably the best bet. But back then, it wasn't.

tuhgdetzhh• 9 months ago

This can also be expressed as general advice.

Whenever you are unsure whether to use a clever solution or follow the globally accepted standard in your work as a DevOps or Software engineer, always choose the standard.

hinkley2• 9 months ago

I can’t quantify how much time my team wasted in diagnosing production glitches on checking the wrong time offsets but it was substantial. One of our systems wasn’t using UTC, and given enough time the fact that Slack wasn’t using it either does become an issue. When an outage transitions to All Hands on Deck everyone needs to get caught up to what’s going on preferably under their own power so you don’t suffer the Adding Resources to a Late Project problem.

So that first alert that came in ?? minutes ago you need to align with the telemetry and logs in order to see what the servers were doing right before everything went to shit.

lxgr21• 9 months ago

While I agree on this particular instance, there are two types of things future engineers have to clean up after: Their predecessors thinking too small (and picking the easy route) or too big (and adding needless complexity).

One is not necessarily and in all instances less of a mess to clean up behind than the other.

fiddlerwoaroof• 9 months ago

This shouldn’t be hard to deal with if the timestamp is always serialized with the offset: I’m much more picky about always persisting the offset than about always persisting UTC

Wowfunhappy• 9 months ago

What if it's your personal machine? I'm thinking about jobs I've set up... thing is, I actually do want those to align to DST in most cases. For example, ZFS scrub should start after I leave for work so that it has the greatest chance of being done by the time I get home. (It's too loud to run overnight.)

devsda• 9 months ago

Java allows setting the default timezone at jvm level and everyone in our org were setting their favourite TZ which was mostly PST somewhere in the code.

We had application logs and system level logs with different timestamp and someone decided a certain db column has to be a string of the format 'yyyy-mm-dd hh:mm:ss". You can imagine the confusion and the "fun" time we had while debugging logs from multiple systems at specific times.

Finally, one lead put their feet down and mandated that setting timezone to PST should be the first thing all applications do and db columns should be considered PST unless otherwise required.

mulmen• 9 months ago

Does that mean you ran PST during daylight savings time and half the year your logs were “off” by an hour? Or did you actually run Pacific Time and deal with the clock changes twice a year?

skissane7• 9 months ago

Finally, one lead put their feet down and mandated that setting timezone to PST should be the first thing all applications do and db columns should be considered PST unless otherwise required.

That seems to me like a really bad mandate. If you are going to mandate something, mandate UTC. If someone forced me to change a system from UTC to something else, I’d not be very happy. It’s the kind of decision which makes you seriously question if you want to work there any more.

lxgr21• 9 months ago

Closely related pet peeve: Log display web UIs that allow selecting display timezones including UTC absolutely insist on deriving my preferred time format (12/24 hours) from my browser language preference.

If nothing else, selecting UTC should be a very strong hint to any UI that I am capable of parsing YYYY-MM-DD and 24 hour times.

webstrand2• 9 months ago

That is the correct and only sane way to determine date format, timezone is not the same as formatting preference. But yeah it sucks. Assuming you're using the en-US locale, have you tried using the en-CA locale? It has ISO8601 formatted dates, and is otherwise pretty similar to the en-US locale.

In firefox you can try it out in about:preferences by setting en-CA as the topmost option in "Choose your preferred language for displaying pages"

And I just checked, firefox is capable of understanding system-wide split locale settings, if you only want LC_TIME

    localectl set-locale en_US.UTF-8
    localectl set-locale LC_TIME=en_CA.UTF-8

and dates will format, but currencies, addresses, etc will not

skissane7• 9 months ago

If you use <input type=time>, the browser uses locale or user regional preferences… even if the app is in an application domain (e.g. medicine, military, science) where 24h is preferred even in 12h-predominant locales. There is no way for the app to say to the browser “this time field should be 24h in all locales”, the only option is to build a custom time field

I asked the HTML spec editors to fix this, but thus far they haven’t: https://github.com/whatwg/html/issues/6698

booi• 9 months ago

That's interesting because I strongly prefer that timestamps are stored as UTC and converted to my timezone on the fly for easier debugging. I dunno about using the browser language choice (do sites really do this)? Usually a simple conversion with javascript is fine (javascript knows the local timezone).

A plus would be showing both.

spelk• 9 months ago

I would especially like to call out the Scandic Hotels chain for this behaviour as well. Booking a hotel room should not involve me wondering if I booked it for the wrong day when I'm not in an European time zone.

silverwind2• 9 months ago

You can blame the browsers on that one. There is now an API to determine hour cycles, but it's not even supported in all browser yet:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

creichenbach• 9 months ago

That's still a bit risky as Arizona might just change its time zone definition on a whim. I'm an engineer on one of the big calendaring applications, and it's mind-boggling how often stuff like this happens world-wide, sometimes short-notice (a few weeks in advance). It regularly gives us headaches.

jaggederest• 9 months ago

Agreed, watching the rate of changes to timezone databases will rapidly disabuse you of the notion of any constant. It's rare that a day goes by without an update to some definition somewhere, which is astounding.

raggles• 9 months ago

I have a job that deliberately runs at 2am and 3am... to update the time in a bunch of really old PLCs for DST. And check that every other device on my telemetry network has correctly updated its time.

PhilipRoman2• 9 months ago

I read this a while ago and was looking forward to the mess that would happen with these default Alpine configurations (after setting non-UTC localtime)

    0 2 * * * run-parts /etc/periodic/daily
    0 3 * * 6 run-parts /etc/periodic/weekly

It appears that busybox cron is smart enough to handle it and only ran the jobs once.

latchkey19• 9 months ago

Google's AI and ChatGPT answer disagrees.

https://www.google.com/search?q=busybox+cron+dst

"BusyBox’s crond is a lightweight implementation designed for embedded systems, so it doesn’t have all the timezone/DST logic of full vixie-cron or cronie. It just reads /etc/TZ or the system timezone at startup and then wakes up every minute to check if something should run."

PhilipRoman2• 9 months ago

https://github.com/mirror/busybox/blob/master/miscutils/cron...

moderateclimate• 9 months ago

Please don't do this. AI is not a source and is frequently wrong (as it is in this case).

matja• 9 months ago

Seems to me the real problem here is not the timezone (there's legitimate business needs to run something daily at a specific localtime...) but having multiple instances of a cron job that overlap, in which case it should wait until the previous is done or not start at all. At least prefix a job with "flock -n" if it doesn't/can't handle that.

tonyhart7• 9 months ago

DST is such a dumb mechanism anyway

just use UTC

skopje• 9 months ago

UTC also solves plotting daily time plots in zones with time changes (twice a year when the plots make no sense). But there still isn't no good fix for leap year plots!

bobmcnamara6• 9 months ago

Just use TAI?

meonkeys• 9 months ago

anacron is worth a mention here for sometimes-on computers like desktops, laptops, or personal servers. It's great for ensuring something runs at the set interval, or just whenever the machine comes back online. Minimum anacron interval is one day, so this can't simply replace cron. cron might even be the most sensible thing to use to kick off anacron on your system, and it might already be in use (see if your /etc/crontab fires off anacron).

anacron won't have the OP's 2am/3am issue because it locks jobs while they run, so multiple job spawns should be no-ops. Still seems like it would be good practice to, e.g. use UTC for the host system and do whatever else might help avoid the unnecessary re-spawns.

litoE• 9 months ago

I run a cronjob at 2:30AM every day that uses dirvish (a perl wrapper around rsync) to perform backups of several computers. In the fall, at 2AM the clock is rolled back to 1AM. The cronjob runs at 2:30AM, which is 25 hours after the previous day's run. That's not a problem. However, in the spring, at 2AM the clock jumps to 3AM. Vixie cron seems to be smart enough to run all the cron jobs that were scheduled between 2M and 3AM at that point. However, dirvish is started but exits without running the backups! After some troubleshooting I concluded that dirvish does not make the backups because the previous day's run happened less that 24 hours ago (because that day was shortened by the change to DST) so it sees no need to run a backup yet. This problem would persist even if I moved the cronjob to a different time because it has to do with the day having only 23 hours. I solved this by adding a second entry to the crontab that runs at 3:45AM only on the 2nd Sunday in March.

tomkaos• 9 months ago

I avoid cron job at this time for this reason and for many other random problem because 3:00 am seem to be often choose for a maintenance like automatic update, server reboot, database backup..

tclancy• 9 months ago

Can be tricky: an old project had a job that ran every 15 minutes to poll data from a popular smart thermostat company. I always knew when DST was starting or ending because that job would throw an error email at 2/3am on those days.

hinkley2• 9 months ago

2 am is mid afternoon for the Pune office. If you’re running a 24/7 operation and all of your employees are in PST you’re gonna have a bad time.

But the other thing that has changed since 2013 is that most of us are using autoscaling. There were times of day when there is supplemental server capacity to run periodic processes, and it made sense to schedule them during quiet daylight hours if they existed, but now the availability of bus numbers if and when a problem happens are more pressing. And they all outweigh concerns about DST. Instead of seeking the low traffic times of day you mainly need to avoid peak traffic.

The batch processing system I renovated to use 7% if the CPU hours of the original design, used the same fixed parallelism trick that crawlers use so as not to knock over your sites. They keep k requests in flight at all times and if your server responds faster, they issue more requests per second. If the production services had excess capacity the job would run in ten minutes. If response times are slow it takes 15. You’re inverting Little’s Law and keeping the amount of servers fixed and varying the duration.

It’s a pity that spooling up more servers to handle that job took a substantial fraction of that ten minutes or I could have gotten it to five (originally it was over 30 minutes and climbing toward 35). I tried at one point to move it entirely to a Bamboo agent but we underprovisioned them. If I’d had an agent with 2x the CPUs I could have shut down a service. I was on my way out the door before I realized that upgrading the bamboo agents would have cost us less than running that service and everyone’s builds would have been faster as a consequence. And probably let someone else do the same. False economies.

brettgriffin• 9 months ago

Alternatively, where possible set the server timezone to UTC so that no daylight savings changes will happen at all.

Is this what people actually want, though?

I'm actually working on a scheduled process right now deployed on a cloud scheduler that does not adjust for daylight saving time (it literally says "does not take into consideration daylight saving time" next to the time input).

Everybody wants the job to run four hours before the work day starts, every day of the year. I will have to change it on Sunday to ensure the job completes at the time the end users expect it. And again in March.

Am I missing something?

monster_truck• 9 months ago

I call this "rake stomping", as long as you're running back and forth in the same places every time, you'll never notice.

waisbrot• 9 months ago

The article is mostly talking about using the `cron` scheduler and running things at 2am on Sunday because there's especially low traffic. These cron jobs are "I don't care when it runs, but it should have minimal chance of causing problems."

Your use-case is totally different: "I want this job to run at this time" so the only lesson that applies to you is that the `cron` utility might behave weird during DST switches. No idea if it underlies your cloud provider, so it may be completely irrelevant.

evil-olive5• 9 months ago

Everybody wants the job to run four hours before the work day starts

recurring events like this - ones that take place relative to humans in a given location - are the most common snag related to "just use UTC everywhere" advice. but they're not actually in conflict at all. they just require an extra layer of indirection.

let's say this is a factory that starts early in the morning, 06:30 local time, because then "four hours before" falls into the window affected by DST.

"run at 02:30 local time" is what you want to avoid, because on the "spring forward" day, 02:30 simply does not exist. the clocks jump from 01:59:59 to 03:00:00. [0]

likewise, "run at 01:30 local time" is to be avoided, because on the "fall back", that occurs twice.

ideally, you want to think of the recurrence as being associated with a given location, and that recurrence generates individual events, which happen in UTC time.

for example, if the factory is in San Francisco, the recurrence might specify "once a day, at 02:30 SF time", which would generate a series of daily events in UTC time. during the summer those events are at 09:30Z, during the winter they're at 10:30Z.

you also want the scheduler to be smart enough to understand the "once a day" constraint - so that a "once a day, at 01:30 local time" task generates only one daily event, rather than two, even though 01:30 local time happens twice in the same day.

and then, because the individual events are all in UTC, and the system clock is as well, there's no ambiguity in the actual execution time of the event. the complexity of the recurrence is handled at a higher level.

if you want an even harder version of this problem, imagine a team in SF and a team in London, that have a Zoom meeting every Monday at 8am (SF) / 4pm (London). it's necessary for one of those locations to "own" the recurrence, because the UK does their time changes 1-3 weeks offset from the US [1], creating weeks where it isn't a straightforward 8 hour time difference.

0: https://www.timeanddate.com/time/change/usa

1: https://www.timeanddate.com/time/change/uk

jay_kyburz3• 9 months ago

The more I read this thread, the more I think this is just a bug in Cron. It should really only operate on UTC, regardless of the local time set on the server.

p0w3n3d• 9 months ago

It depends on tz. 4 am in some countries too

sedatk• 9 months ago

Redundantly running cron jobs are the least of our problems. Daylight savings adjustment day causes surge in deaths and ER visits[1]. Daylight savings needs to go.

https://www.sciencealert.com/daylight-savings-time-change-ki...

HiPhish3• 9 months ago

DST was a mistake and it needs to die. It solves no problems and only creates them. And not even the type of problem that someone could profit from, just plain old complete waste of time for everyone problems.

Just stick to winter time (because that's the correct one) and adjust all working hours once and for all to be like summer time, for e.g. instead of business opening at 7AM and closing at 10PM they can open at 6AM and close a 9PM. There will be a period of adjustment, but we have a period of adjustment twice a year already, so nothing is lost.

Why match working hours to summer time? Because I want to have more sunlight by the time I'm done with work. Especially during winter. We have it completely backwards, if we are going to adjust our clocks we should adjust them in a way that gives us more sunlight during winter, not less. I don't care if it's dawning by the time I'm going to work where I will be stuck indoors for nine hours, I want sunlight when I'm free again.

StopDisinfo9104• 9 months ago

So you propose we stop shifting the clock but shift every opening and closing times instead producing exactly the same effect with basically no difference.

And you want to abolish DST but the end of your comment is that you actually want even more shift including in winter.

I fear I have trouble following your reasoning and understanding what you actually want.

xigoi• 9 months ago

If I’m reading the parent correctly, they Want to switch to non-summer time and adjust opening hours to be effectively like summer time, forever.

cameldrv• 9 months ago

Yes shift the opening and closing times of everything. Get everyone to coordinate, so that your kids' school time doesn't shift relative to when you need to be at work, not to mention everything else where two different organizations have to do something that regularly happens at a particular time. Give up eliding this whole problem so that some programmers have an easier time scheduling backups or database compaction.

In fact, as some have suggested, we should also give up time zones and just use UTC for everything. That way when you have to schedule a Zoom call a few thousand miles away, there is no confusion as to the time. Some idiot might retort that since people like to sleep when it's dark, that instead of looking up the time zone difference, you'd have to look up what time the sun rises where they live.

I say screw them. Half of the world should just learn to live with sleeping during the "day" and go to work at "night." We've got electric lights now. It's a small price to pay so that programmers don't have to do time zone conversions.

malfist• 9 months ago

Stores already do this. Check your hours at your local mall, Kroger or Lowes.

HiPhish3• 9 months ago

So you propose we stop shifting the clock but shift every opening and closing times instead producing exactly the same effect with basically no difference.

Lol no, that would be indeed even worse. I want to do the shift once and forever. Well, first and foremost I want to get rid of the twice-a-year switch. The question that usually arises then is "should we be permanently on standard time or on DST", to which my proposal is standard time (because it's correct) but shift working hours once and forever so we have more sunlight all year around. During summer it would be the same as it already is and during winter we have one more hour of sunshine, which is the time of the year when I want sunshine the most.

butlike• 9 months ago

There's more clocks than storefronts

candiddevmike• 9 months ago

I'm all for abolishing DST, but I'm not sure which one I'd choose, both have trade offs.

gpvos2• 9 months ago

Um, no? Using standard time in summer (assuming northern hemisphere) means that the time will be earlier when the sun goes up and under. So it will be darker at 9 PM and easier to put your children to bed. They may get up earlier though.

sllabres• 9 months ago

I don't want to be petty, but there is no 'winter time', only standard time and summer time or 'daylight saving time'.

I first heard the term 'winter time' when it was discussed to decide weather to keep DST permanently or if people would like to keep 'winter time' always. And of course who would want to have winter-something always. ;)

keithwinstein2• 9 months ago

If we're being really pedantic, in the U.S. context the zones observe "standard time" all year. "Standard time" refers to the standardization across the zone, and the practice of advancing the clock during daylight-saving time changes each zone's standard time. The Unix-style usage of "EST" vs. "EDT" isn't pedantically correct (e.g., New York observes "eastern standard time" even in summer).

See 15 U.S.C. §§ 260a & 263 (https://www.law.cornell.edu/uscode/text/15/chapter-6/subchap...).

endgame3• 9 months ago

Everyone carries a GPS in their pocket; why not use it for good? We can have people's clocks continually update so that 12:00 is solar noon at their current location each day, and avoid the jarring transitions into and out of DST.

Don't ask what people living in the high altitudes will do - I'm still working on that.

joshAg2• 9 months ago

please don't ditch timezones.

https://qntm.org/continuous

pantalaimon• 9 months ago

That's what people did before time zones were a thing. Is caused a major hassle for railway schedules when those started to be all the rage.

TylerE5• 9 months ago

Do you not appreciate how incredibly annoying it would be if the clocks in the next town over were 5 minutes ahead of yours?

pseudalopex3• 9 months ago

Don't ask what people living in the high altitudes will do - I'm still working on that.

You meant latitudes?

bloppe6• 9 months ago

It's only actually an issue at the poles. Even 10 meters away from the pole, there's technically going to be a solar noon.

tzs• 9 months ago

Continuously updating clocks is an interesting idea, but it isn't solar noon that you want to to anchor it to. That doesn't really accomplish anything biologically useful.

It is sunrise you want to anchor it to, because it is sunrise that our circadian rhythms sync to.

rick_floss• 9 months ago

”Lets meet at the coffeeshop in town X at 5pm” becomes a real difficult thing to orchestrate.

dkersten6• 9 months ago

because that's the correct one

No it’s not. We assigned the meaning of time, we can assign it one hour shifted. Or better yet, just ditch timezones altogether.

Summer time is much better where I am, winter days wouldn’t get dark quite so stupid early.

joshAg2• 9 months ago

please don't ditch timezones.

https://qntm.org/abolish

piva00• 9 months ago

Same, I hate this last weekend of October when sunset suddenly shifts from 17.00 to 16.00, it makes the winter darkness so much worse... It'll be dark before I start and end work anyway (on solstice it's 8.30-14.30), at least let me have sunlight a little later in the day so I won't feel as miserable.

aaronblohowiak• 9 months ago

Yes, about 14 years ago I made http://the.endoftimezones.com as a lark. its probably the thing I've made that's been in prod the longest.

icedchai• 9 months ago

Summer time definitely "feels" better to me. The early sunsets in winter are super depressing.

HiPhish3• 9 months ago

Noon should be a 12 o'clock. So whichever of the two times is closer to 12 o'clock during noon in the middle of the time zone should be the one time. I don't really care if it's DST or standard time, just pick one and if necessary adjust working hours so we get that one extra hour of sunlight during winter.

dathinab8• 9 months ago

Or better yet, just ditch timezones altogether.

that is quite a terrible idea IMHO (at least if done internationally)

sure they make international meetings/events harder, but for most people most of their live is bound to local time meanings even if you travel to another country. 7am is in the morning 7pm in the evening 11:59am is mid day etc. If you remove time zone then for some people 7am is morning for other it's mid day and for other noon. So creating a lot of issues for everyone just to make international remote meetings and events easier seems like a bad idea, not even considering the absurde level of practical issues a switch like that would cause for any country not around UTC+0. Even more so remote meetings and events normally involve software and and time zone confusions are very solvable there (display time dynamically in the time zone device currently displaying it (but with time zone suffix, and some considerations about storage wrt. changing time zones, also maybe add an option to display in home instead of current time zone)). Annoying is how few programs do that properly.

wormius• 9 months ago

Oh the halcyon days of Swatch Internet Time measured in .beats (1000 .beats to a day)

https://en.wikipedia.org/wiki/Swatch_Internet_Time

I love that it's metric. One would think they'd at least give homage to 1024, but it's Switzerland so they gotta shove mod10 in our faces.

hsbauauvhabzb2• 9 months ago

In theory this is nice assuming you push the opening hours back but the cost of it would be significantly more than the developer time wasted by a mile.

Binding times to timezones to geographic locations (which have different sunrise and sunset times) to opening hours to social stigmas (you wake up after 11am? Tisk tisk) is downright silly, but humans don’t like change so fixing it will never happen.

gilfoy• 9 months ago

NC has a house bill that has not passed committee to abolish DST, and a senate bill to only have DST.

anal_reactor3• 9 months ago

I agree with you except I think we should stick to summer time because it's obviously the correct one. And hence the whole debate.

throwaway1063823• 9 months ago

How about we cut the baby in half and just shift back by 30 minutes.

dathinab8• 9 months ago

DST wasn't a mistake and did make a lot of time (at least if you are far enough away from the equator). Heck if you go back far enough local time might have varied by session/be relative to sun rise, and that did make sense in the past.

What is the mistake is keeping it.

Through changes need to be coordinated (e.g. in the EU across _all_ EU member states), which makes it an annoying topic to takle.

That people tent to say "keep winter time" but it directly conflict with what sleep scientist tend to recommend is not helping either. In the end normal time is summer time and it is better for most peoples sleep rithm that is what we should go to.

Oh also don't shift work start/end times, the whole point is to not shift when you need to wake up/go to bed but can have consistent healthy sleep.

dathinab8• 9 months ago

PS: on the other hand the affect on sleep might not matter (as in there are many far large effects). I live north enough for the number of sunlight hours and sunrise/set in summer and winter to massively differ, with the sky never getting fully dark during the few longest days.

bloppe6• 9 months ago

In the end normal time is summer time

I think you have this backward. Standard time is during winter. Daylight savings is during summer.

That being said, I used to hate the switch, like you. Now, I'm convinced it's the best of only bad options. Just look at the history of DST. We've tried it all. We've tried year-round standard time. We've tried year-round DST. We've tried switching at all sorts of different dates. Every system has it's problems and it's advantages. The current system is basically the one that actually pissed people off the least.

bloppe6• 9 months ago

Everybody think DST is the worst and needs to be replaced in some way or another. Most people don't realize that their proposed "solution" has already been tried. Your particular solution of "year-round DST" was tried in America in 1973-1975. I'll just quote Wikipedia:

During the 1973 oil embargo by the Organization of Arab Petroleum Exporting Countries (OAPEC), in an effort to conserve fuel, Congress enacted a trial period of year-round DST (P.L. 93-182), beginning January 6, 1974, and ending April 27, 1975.[17] The trial was hotly debated. Those in favor pointed to increased daylight hours in the summer evening: more time for recreation, reduced lighting and heating demands, reduced crime, and reduced automobile accidents. The opposition was concerned about children leaving for school in the dark and the construction industry was concerned about morning accidents.[18] After several morning traffic accidents involving schoolchildren in Florida, including eight children who were killed, Governor Reubin Askew asked for the year-round law to be repealed.[19]
Over three months from December to March, public support dropped from 79% to 42%.[19] Some schools moved their start times later.[19] Shortly after the end of the Watergate scandal caused a change of administration, the act was amended in October 1974 (P.L. 93-434) to return to standard time for four months, beginning October 27, 1974, and ending February 23, 1975, when DST resumed.[18][20] When the trial ended in October 1975, the country returned to observing summer DST (with the aforementioned exceptions).[12]

BobaFloutist2• 9 months ago

Have we tried my solution of having a continuous curve of time adjustments instead of one big discrete jump? I think that would have been awful in the day of manually set, analog clocks, but surely in 2025 when everything's digital and many things are connected it's totally possible, no?

derektank• 9 months ago

Outdoor lighting is a lot cheaper now than it was in the 1970s. I think we can give it another shot after 50 years. And it's worth pointing out that Arizona has gone without DST for the last 50 years and seems to be doing fine.

maest2• 9 months ago

The world extends beyond the US and many countries have successfully abolished DST. But maybe America is exceptional in some way, sure.

StopDisinfo9104• 9 months ago

France has year round DST and an hour on top during summer since 1940 and far less car accidents than the USA both in the morning and in the evening. So does Spain and Portugal but I'm too lazy to check since when. I don't think automobile accidents is a very good metric to evaluate the interest.

It's basically a trade off between light in the morning and the evening. When Britain tried, they saw that it was mainly impactless with regards to the total number of accidents. They still reverted.

nostrademons3• 9 months ago

Schools in the U.S. in general start way too early. The AAP recommends no earlier than 8:30 AM [1]; the average across the U.S. is 8:00 AM [2], and close to 20% of suburban high schools start before 7:30 AM. An 8:30 AM start time would be after sunrise in every major municipality in the U.S; sunrise in Seattle and Duluth (the most northerly major cities in the continental U.S.) on Dec 21 is at 7:55 AM.

GP was proposing year-round standard time, not year-round DST.

[1] https://www.apa.org/topics/children/school-start-times

[2] https://nces.ed.gov/pubs2020/2020006/index.asp

bmandale3• 9 months ago

DST is just a hack to make the time roughly correspond to when the sun rises, instead of when noon is. It solves the problem that people want their day to start when the sun is up, not before, and not after. The problems it creates are mostly for programmers who can't be bothered to write good software. Well I say tough cookies, you'll have to handle the edge cases so the rest of us have comfortable mornings.

Mistletoe2• 9 months ago

I don’t give a crap about the day starting when the sun comes up. I just want to go home at 5PM in winter and it not be dark already. There are plenty of studies about how this increases depression in the winter. The fact we keep persisting with this perverse nonsense infuriates me.

maest2• 9 months ago

The problems it creates are mostly for programmers who can't be bothered to write good software

Myopic and ill informed.

A 2017 study in the American Economic Journal: Applied Economics estimated that "the transition into DST caused over 30 deaths at a social cost of $275 million annually", primarily by increasing sleep deprivation.[128]

From https://en.wikipedia.org/wiki/Daylight_saving_time, Effects on Health section. That section mentions many more negative effects of DST.

nostrademons3• 9 months ago

It's a pretty imperfect hack, since in many parts of the continental US the sun still rises at 5:00 AM even with DST, and you still get up in darkness in the winter. It was dark when I woke up today, for example.

LeonB• 9 months ago

In Superman III, the eponymous man straightens the leaning tower of Pisa, and in Superman II he spins the earth backwards to reverse time.

A better idea would be to un-tilt the earth’s axis, thus getting rid of variable day lengths, annual seasons, the need for DST etc, just one enjoyable spring day, every where, all year round.

saghm• 9 months ago

So much of the discussion that happens around DST always end up coming across to me like they're based on people's subjective experiences that they seem to assume apply universally (or close enough to it to structure society around, with the assumption that only a small fraction of people don't experience things similarly). I don't think things are nearly so simple, and while having issues strong enough to be diagnosed with a condition like the ones I mentioned above is probably not super common, it seems pretty plausible to me that there's a lot more of a spectrum than just "people whose circadian rhythm perfectly matches the sun" and "outliers whose circadian rhythms are designed misaligned with the first group". It just doesn't seem obvious to me that the issue couldn't be that some people have different enough experiences in terms of their circadian rhythms that their optimal clock scheme might be an hour earlier or later than someone else, or that one person might be greatly affected by the total length of the sunlight in the day and another might be completely indifferent to it.

There are a number of disorders[1][2][3][4] that relate to circadian rhythm, and I don't think it's that much of a stretch to imagine that even outside the bounds of a diagnosable condition people's experiences might be a spectrum rather than a binary of "majority of people who would all have the optimal experience with the exact same scheme for how clock time should work" and "small fraction of outliers who wouldn't agree with the obvious best solution that everyone else would". It's absolutely wild to me how many people feel so strongly about the "correct" way to handle this that when examined basically boil down to "well, this is what would make me happy". I don't doubt that people probably are correct about what would work better for them, but I also don't think it's that crazy to think that it might not be that uncommon for two arbitrary people to have optimal clock schemes that differ by an hour or more, or that whether or not their optimal clock scheme might vary direct by the time of year, especially given that the length of sunlight in a day isn't at all uniform at different latitudes.

I don't pretend to know for sure whether DST is right or not, or what the correct hours to pick in the absence of it would be, but I can't help but be skeptical of an argument that it "needs to die and solves no problems" and that a certain time is the "correct" one because "I want <something>". It's totally valid to want and even argue for something, but that's not at all the same as anything else being automatically incorrect when your way of getting it is literally to enforce how time works for millions of people. Phrasing it like that just doesn't make it sound like your arguments are going to be very convincing.

[1] https://en.wikipedia.org/wiki/Circadian_rhythm_sleep_disorde...

duskdozer2• 9 months ago

A lot of the conflict over which of daylight and standard time is better would be solved by allowing people more freedom to choose their own working hours. A lot of the rhetoric around it seems to be about what the optimal sleep-wake schedule is, which strangely tends to match up with the speaker's own sleep-wake schedule.

cmiles8• 9 months ago

Or just use UTC and stop using timezones in code. I get it’s not that simple for some use cases but UTC exists for a reason.

bobmcnamara6• 9 months ago

Use TAI.

UTC has most of the same wacky timezone problems, just less often.

ericpauley2• 9 months ago

You’re signing up for a world of pain in the real world, where every other system is UTC. Just use UT1 or smear the leap second if you really can’t stand the risk.

MayeulC• 9 months ago

Not a crown job, but I configured my lights to turn on progressively at my scheduled wake up time, using Home Assistant.

I figured that scheduling lights to turn on at <0 AM + wake up time> was a good approach... We got a surprise early wake up last year, so I ended up changing the formula to <4 AM - 4 hours + wake-up time>.

cadamsdotcom• 9 months ago

Great to read about something that's a solved problem now. It's been a very long time since I used a server that wasn't set to UTC.

bobmcnamara6• 9 months ago

I've seen this same problem under UTC. Gotta use TAI

ckastner2• 9 months ago

This was worked around ages ago in OpenBSD, and the workaround was already included in Debian (and by extension, Ubuntu) when I started maintaining it in 2010 (I no longer do).

Here's a link to a patch [1] from a version from when the package still kept standalone patches.

It's been a long long time and I honestly don't remember the details, but Debian's cron(8) still says [2]: Special considerations exist when the clock is changed by less than 3 hours, for example at the beginning and end of daylight savings time. If the time has moved forwards, those jobs which would have run in the time that was skipped will be run soon after the change. Conversely, if the time has moved backwards by less than 3 hours, those jobs that fall into the repeated time will not be re-run.

Edit: According to this bug report [3], this workaround first entered Debian in 1999.

[1] https://sources.debian.org/src/cron/3.0pl1-137/debian/patche...

[2] https://manpages.debian.org/unstable/cron/cron.8.en.html

[3] https://bugs.debian.org/8499

silverwind2• 9 months ago

So we can assume the author was not running a distro that had "fixed" the issue?

ckastner2• 9 months ago

Most likely, yes. The author mentions vixie-cron, which was the name of the project before Paul Pixie joined/founded(?) ISC, and it was released as ISC from after.

Debian's fork is still based on vixie-cron, but it couldn't have been the one because of the aforementioned patch.

jcynix2• 9 months ago

better open source job scheduler [...] one that will ensure no overlapping runs

Or learn to use lock files, which would make sure that your jobs don't run when another one is already running?

Unix shells offer the trap command, among other things, to cleanup, even in the case of errors, e.g.:

   set -e
   LOCK=$(ensure-lock)
   trap "rm $LOCK" 0 1 2 15
   do-job

https://en.wikipedia.org/wiki/Semaphore_%28programming%29

TylerE5• 9 months ago

Tell me how that goes after a server malfunction or power failure. Where is your trap god then?

jcynix2• 9 months ago

The topic was to prevent overlapping runs. In case of power failures etc all your server processes have this problem. That's why, for example, /var/run exists and files/directories are deleted from /var/run on reboot?

magarnicle3• 9 months ago

The problem is not so much which timezone you pick, the problem is that cron uses 'naive' datetimes. If the timezone is explicit then you don't have duplicate hours because one is 02:00 and one is 02:00DST.

And then you can translate that time to any other timezone with ease, knowing that you are referencing a specific hour in physical time that only ever happened once.

magarnicle3• 9 months ago

Which is to say I wish cron had the TZ variable that Jenkins uses in it's scheduling system. And the H value to easily spread multiple jobs over the hour/day/month etc.

LeoPanthera• 9 months ago

knowing that you are referencing a specific hour in physical time that only ever happened once

"Falsehoods programmers believe about time"

This assumption can break with:

* Leap seconds

* Calendar and time zone changes

* (In exotic circumstances) Relativity

magarnicle3• 9 months ago

I'll give you leap seconds, but at least in Python historical timezone changes are recorded in the datetime library, so the timezone at any particular time in the past has the timezone offset that was active then.

atoav• 9 months ago

If you want to avoid overlapping runs simply simply have the task check for the existence of a lockfile, if not create a lockfile containing the start timestamp, run the task and delete the lockfile at exit or error.

The timestamp gives you a chance to recognize stale/orphraned lock files in case of crashes based on their age.

loodish• 9 months ago

I like cron jobs that run during the work day. If something goes wrong I would prefer to handle it at 10am rather than 10pm. Why make life unpleasant?

If it really needs to run during a low load period I line it up for 6am work time. Again so that if something goes wrong it leads into the work day rather than disrupts the on-call too badly. 6am also provides a daylight savings buffer either way so you don't have to care. Recent work has all been on 24/7 operations though.

dathinab8• 9 months ago

2-3am is bad due to DST but there is another reason to also avoid 3-5am or so

around 3am is the time where "in average" human attention is the worst as its where "in average" their most relevant deep sleep phases are

now I guess the average over HN readers has a good chance to be somewhat later

but either way if the job goes wrong and triggers alarms 2-5am it very bad for the the health and sleep rithm of whoever needs to fix it and the most likely time they make mistakes

it sadly is also the time where non-international interruptions are least likely to matter

if you are an international company having international teams can be an solution

and if you are a very small team adopting job times to an overlap of low usage and your admins sleep habits can be an option

but if you need to pick a generic time and don't provide for logistics or other "start work at 4/5am" companies probably 5-6am is a better time to run your batch jobs

anyway just some random thoughts

tanin• 9 months ago

The details I never really thought about until I encountered timezone issues was:

There are points in time that don't exist, and there are points in time that are ambiguous.

If we adjust the time forward by 1 hour, then then 2:30am doesn't exist. If we adjust time backward, then 2:30am is ambiguous.

2am-3am is only safe for certain countries.

America/Santiago (Chile), for example, adjusts their daylight saving on midnight. On a certain day, midnight doesn't exist because it immediately jumps to 1am. If you are building an analytics chart by day, you will encounter this issue. I wrote about several weird time zone edgecases here: https://tanin.nanakorn.com/edgecases-for-timezones/

To add more confusion, IIRC Java and Ruby handle these cases differently where Ruby raises exceptions (e.g. InvalidTime and AmbiguousTime) but Java doesn't.

I caused 3 incidents in a row at Stripe in my first month because of this. I thought I was gonna be fired. Luckily I wasn't...

ray_v3• 9 months ago

Here's my radical time idea: instead of keeping the same schedule year round, we just incrementally chop parts of the day off (we just put that time in a "bucket" and pretend it doesn't exist). Then at the summer equinox we empty the time bucket into a 6 day bender of a party. /s

tsoukase• 9 months ago

For the most part of Europe and USA the day is either "quite" long (summer) or quite short (winter) due to the curve of the duration. Having light for long summer evenings and dark for long winter mornings is bad for many reasons, one of witch is seasonal depression, with which the Scandinavians suffer and fight. I was for the abolishment of DST until COVID cancelled it in Europe but now I am thinking it again and probably I am against.

Zanfa• 9 months ago

While not always possible, in general, any mission critical scheduled job should be idempotent. This avoids so much headache, especially when there's a queue involved somewhere.

nubinetwork• 9 months ago

Doesn't systemd timers fix this? AFAIK, a job set to run once a day shouldn't run a second time because the time rolled back.

sharts• 9 months ago

Why run crons at that time anyway? It seems the most logical times for things are going to be midnight or beginning/end of business day.

tokyovigilante• 9 months ago

Whatever argument you may have against DST, “my cron jobs won’t run twice a year!” is not a strong one.

Avoid 2:00 and 3:00 am cron jobs (2013)

Related Stories