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.
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.
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.
Among other things, in an incident, people’s brains aren’t working - the more they have to remember about your particular system, the more likely they are to forget something.
it was already a 40 year old standard at the time you're talking about.
awareness of UTC being the correct choice has definitely increased over time, but UTC being the correct choice has not changed.
you say reddit servers use UTC now, which implies there was a cutover at some point. were you still at reddit when that happened? were you still hands-on with server maintenance? any anecdotes or war stories from that switchover you want to share?
because I can easily imagine parts of the system taking a subtle dependency on Arizona being Reddit Standard Time, and the transition to UTC causing headaches when that assumption was broken. your memory of this "clever" trick might be different if you had to clean up the eventual mess as well.
Hold on, I'm not a sysadmin guy. Are you folks saying the server should not know what part of the world its in, that basically it should think it's in Greenwitch?
I would have thought you configure the server to know where it is have it clock set correctly for the local time zone, and the software running on the server should operate on UTC.
1) Most software gets its timestamps from the system clock
2) If you have a mismatch between the system time and the application time, then you just have log timestamps that don't match up; it's a nightmare - even more so around DST/ST transitions
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.
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.
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
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.
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.
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.
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
Some browser APIs respect `LC_TIME`. Others say "fuck standards, I'm using `LC_MESSAGES`".
This means that if those locales differ about say, y/m/d ordering, it is quite possible for the way the browser formats a date to be different than the way it parses the date.
Operating systems generally allow user override of locale settings, and browsers generally respect that; I use a locale which officially has 12 hour time as its standard (Australian English), and I always override it to 24 hour time in user preferences (although Australia is rather inconsistent, e.g. in Sydney, train services use 24 hour time; in Melbourne, the metro trains use 12 hour time but the regional services use 24 hour time)
Interesting, so you're saying that that OS-level time preference is available via JavaScript? I wasn't able to figure out how to query that in a little bit of trying, so I assumed there was no API for it.
If there actually is, I'm now even more upset at that log web UI.
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).
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
> That is the correct and only sane way to determine date format, timezone is not the same as formatting preference.
That's unfortunate, but then wouldn't the sane way for localization-aware software be to ask the user and not make any such assumptions?
> 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.
Thanks, I'll give that a try tomorrow! If my log exploring UI of, well, not quite choice actually respects that, I'll be very grateful :)
In a way it is asking the user. Date formatting rules are traditionally tied to locale, so the user picks their locale and their expected date formatting rules are derived from that.
On Linux you can mix and match via LC_*= environmental variables, but that appears to be complexity the browser vendors didn't expose in their UI.
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.
> 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.
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?
> 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.
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.
If this is a complexity battle, I'd rather that sysadmins have to use a tool to read logs vs. figuring out why the server is melting down because all the jobs are running 2x or answering questions about why jobs didn't run at all.
In my old gig, jobs ran for many many HOURS and consumed most of the IO on the server (processing reams of data), which meant that when you got them running 2x because of overlap, it was a trainwreck.
In my experience, it's really not pleasant having to work with logs that require a dedicated viewer compared to regular old text files I can use Unix commands available everywhere (`tail`, `head`, `wc` etc), with, i.e. not just on the server producing the logs, but also the device I'm viewing them on.
That said, I absolutely prefer UTC times in logfiles. I'd rather do some math every time than make wrong assumptions about the local timezone of the file even once. (Even correctly indicated local times are more annoying, since I have the math for the offset of my timezone to UTC memorized, but not that of every possible server time to mine.)
Yup. There's always some kind of tool anyway so why not. I mean, even if you read the logs as they come out of a screaming line printer, the tool is the thing that takes log messages and spits them out the printer port.
How hard can it be to write a log cat utility in awk?
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.
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.
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.
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.
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. ;)
> most people expected your servers to be in Pacific or Eastern time
I was there back then, working for shops people have heard of, and I honestly don't know where you're getting this idea from. Some places did things wild and wacky when they were wee small, but most of us quickly learned that such shenanigans (like fun server naming conventions) start to fall apart and maybe we should do things differently.
Ah you think UTC is your ally? You merely adopted UTC. I was born in it, molded by it. I didn't see DST until I was already a man, by then it was nothing to me but blinding!
In the 1980s, PT and ET were common. I was working at Bell Labs then, and one of my jobs was to change the time zone (back then it was two words) on the testing machines, as needed. This is stuck in my memory since to change the timezone, you needed to edit the Unix kernel source code and recompile it!
2000 for me. That was the first time I had users from outside my own time zone, so I figured it was better to just use UTC for everything and just convert depending on the user's settings. I think I just applied the thinking to the whole server.
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.
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.
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.
"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.
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.
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.
> 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.
That sounds a bit like reimplementing a scheduler inside the scheduled task (which is ok if you don't trust your scheduler, but I'd avoid it if at all possible).
> Hopefully just a datetime recent enough that the job does not currently need to be (re-)run.
I can think of several ways to mess that seemingly trivial calculation up just from the top of my head. (Consider changing timezones, increasing the interval the job is running to within half a day of scheduling period etc.)
> "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.
Really depends on your market and customers. Especially in the financial industry, local time zones (often of a given currency's central bank's main branch, a primary regulator etc.) are often very, very entrenched.
> Many people will accept UTC because it is the international standard.
I really wish that were true universally...
And I do think that UTC is actually somewhat Eurocentric! From personal experience, it's significantly easier to mentally add/subtract one or two hours (modulo 24) than 7 or more.
> 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.
Definitely, but on the other hand, I do think that picking your head office's time zone as the "canonical" one for resetting quotas etc. has some merit as well, if only because it makes the concepts of "today" and "tomorrow" work a bit better. (UTC midnight might be very unintuitive to both you and your customers.)
> Definitely, but on the other hand, I do think that picking your head office's time zone as the "canonical"
What happens when you move your head office to a different time zone? e.g. Oracle moved their HQ from California to Texas (and have announced a further move to Tennessee, although last I heard that still hasn’t happened)
What happens when an M&A happens and you are now part of a much larger enterprise with a different HQ timezone, and systems with wildly inconsistent configured timezones due to having acquired multiple companies which had HQs in different time zones and all of which configured everything to use their HQ time?
> UTC midnight might be very unintuitive to both you and your customers
I live in eastern Australia, UTC+11 at the moment (UTC+10 during Southern Hemisphere winter). Right now, resetting stuff at UTC midnight means at 11am my time, resetting stuff at US Eastern midnight means at 3pm my time - roughly equal in potential inconvenience, but I’ll be much more forgiving of the first than the second.
> And I do think that UTC is actually somewhat Eurocentric! From personal experience, it's significantly easier to mentally add/subtract one or two hours (modulo 24) than 7 or more.
For me, add/subtract 10 is pretty easy… and then just one more during DST. Does that make UTC “Australia-centric”? Or Guam-centric or Vladivostok-centric? (both of which are also UTC+10)
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. This is exactly what I said above.
> Generate before and send to everyone based on timezone.
How are you going to do this? Clearly cron (with timezone set to UTC) doesn't work for this so you'll need another system. In that case why not have that multi-time zone scheduling system run your script?
I absolutely want some daily business reports to cover 25 hours on one day of the year and 23 on another, since that's how long a calendar day is in local time in every place that has DST shifts.
> That doesn't fix the problem of "my quota reset (or reporting job) gets shifted by 1 hr when daylight saving time changes".
How hard is to convert the UTC time to user's local time and perform quota reset?
I mean you should be doing this anyway. Even if you store everything in PST or EST or CST, you never know when you'll get customers from another part of the world and then you'll have to do this anyway. So why not do this already?
>Even if you store everything in PST or EST or CST, you never know when you'll get customers from another part of the world and then you'll have to do this anyway. So why not do this already?
1. allowing users to change their timezone and tying it to when their quota reset sounds like a great way to add more edge cases and complexity. For instance, does messing with your time zone mean you can get your quota reset multiple times a day?
2. Not everyone operates some sort of global b2c SaaS that's timezone agnostic. For many enterprise backoffice tasks "6am HQ time" is far more reasonable than "6am/7am, dunno depends on whether daylight saving time is on or not". In this case having a server set to the HQ's timezone makes far more sense than doing UTC and trying to work around daylight saving issues.
> How hard is to convert the UTC time to user's local time and perform quota reset?
Probably roughly as hard as writing a timezone-aware scheduler that considers all edge cases around daylight savings time, i.e. probably possible but I'd try fairly hard to see if I can get around it.
One way of getting around it is to run your batch jobs in your "primary business timezone". Sure, you might outgrow that concept eventually, but many companies never do, and in that sense "running on UTC" seems similarly aspirational in spirit (albeit at a much smaller scale) to starting with high scalability.
You could have the reset script check the timezone of the user before actually performing the reset, and have this script run at least once an hour to make sure you get close to accurate for most people (some timezones only differ by less than an hour though!).
But also, if the user can change the timezone themselves, now you have a condition where the user could keep their quota at bay for a very long time (if not forever) if they keep changing their timezone accordingly.
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.
Don't forget changing the day 1/3 of the time. But more importantly, if I'm scrambling to solve an incident, the last thing I want to do is deal with time conversions in my head.
You just do it once and think in UTC going forward. But as I said to the other person, if you're only dealing with one timezone it's fine, just when you have multiple it's a lot easier to just deal with one time and let everyone convert.
I'd expect everyone who works in computer related jobs to know their UTC offset.
I'm able to subtract 8, but if I'm scanning logs it's one more thing to process.
If it's local time I know instantly when something happened, without having to do mental math.
Is there anything wrong with ISO8601 (including timezone offset) for storing times? They're in my local time, but they can be accurately converted to any other timezone.
No problem as long as it's all local, but it's a big annoyance to the other teams if I'm trying to coordinate with the West US team who're on PT, the East coast on ET, Europe on CET, India on IST, Australia on BBQ...
It's just easier for everyone if we agree on UTC and everyone knows their own offset.
Yeah. I log in json + unix timestamp nanoseconds, and just convert it to something human-readable on display (github.com/jrockway/json-logs). I am not sure why logs need to be "pretty" at time of logging when they can be made pretty at time of display. Doing it at time of display means you can just use local time, and then nobody is confused.
Nobody hurt them. Please don't do this kind of childish rebuttals. It looks really silly on HN. If you don't want to use UTC, that's one thing. You do you. But there are reasons for sane professionals (who weren't hurt by anybody) to expect their coworkers to use UTC when possible. Because using local timezone leads to some problems including the one in TFA.
Well me, I have been burned by fixing this UTC bug at like 8 companies and overall more than four year of my life (between other things, each project took at least six months of people poking at things) because at an eventual scaling point it starts biting your ass everywhere in every service.
Just because it worked once doesn't mean it's good.
I find all the holier-than-thou UTC worship especially ironic given that this post is about recurring scheduled tasks, for which naïve UTC almost never provides the expected results
UTC is the right choice for representing specific moments in time (so yes, log timestamps) but there are so many pitfalls outside of that narrow use case
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.
How about I use some form of library to do it. I tell it I want to run at 0800 London time, and it runs at 0800 London time
If I tell it I want to run at 0130 London time (or 0330 Athens time) I still have a problem -- do I run it twice when the clocks go back, do I skip it when clocks go forward?
But that's a business logic problem, and defining it as UTC and having another job to update the time twice a year doesn't actually solve the question of "what do I do at this point".
You don't have any choice in the matter. If you control the time you want the jobs to run externally from the server, then you can have control over it. Otherwise, you're getting jobs that run 2x or not at all.
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.
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.
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.
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.
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?
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.
Better to think of it that it changes at 01:00 UTC, which takes care of the parts of Europe that are 2 or 3 hours ahead (instead of CET's 1 or 2), and the UK going "forward at 1 and back at 2"
"Europe DST changes at 01:00 UTC" - much simpler ;)
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.
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".
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.
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.
> 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.
> 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.
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.
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.
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.
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.
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)
"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."
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.
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.
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..
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.
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!
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.
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.
> 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.
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.
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.
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.
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.
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.
The Principle of Least Surprise.
Among other things, in an incident, people’s brains aren’t working - the more they have to remember about your particular system, the more likely they are to forget something.
Nowadays I'd agree with you, UTC is probably the best bet. But back then, it wasn't.
> But back then, it wasn't.
UTC was standardized in 1963 [0]
it was already a 40 year old standard at the time you're talking about.
awareness of UTC being the correct choice has definitely increased over time, but UTC being the correct choice has not changed.
you say reddit servers use UTC now, which implies there was a cutover at some point. were you still at reddit when that happened? were you still hands-on with server maintenance? any anecdotes or war stories from that switchover you want to share?
because I can easily imagine parts of the system taking a subtle dependency on Arizona being Reddit Standard Time, and the transition to UTC causing headaches when that assumption was broken. your memory of this "clever" trick might be different if you had to clean up the eventual mess as well.
0: https://en.wikipedia.org/wiki/Coordinated_Universal_Time
using utc on servers was very common in 2005
Common, but not universal - from 2005 to as late as 2014 I worked for companies that used Pacific time on their servers.
I’d say it was common enough but not universally, given the number of arguments I had from 2005 to 2015 about this exact issue.
Hold on, I'm not a sysadmin guy. Are you folks saying the server should not know what part of the world its in, that basically it should think it's in Greenwitch?
I would have thought you configure the server to know where it is have it clock set correctly for the local time zone, and the software running on the server should operate on UTC.
1) Most software gets its timestamps from the system clock 2) If you have a mismatch between the system time and the application time, then you just have log timestamps that don't match up; it's a nightmare - even more so around DST/ST transitions
the standard for service providers was UTC in 1995
I have photos showing that my dad (born 1949, never in the military) kept his watch on UTC in the early 70s.
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.
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.
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
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.
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.
It might be instructive for PHBs to have a 'hasatimezonechanged.com' website counting the days since the last timezone DB change...
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.
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
It gets worse.
Some browser APIs respect `LC_TIME`. Others say "fuck standards, I'm using `LC_MESSAGES`".
This means that if those locales differ about say, y/m/d ordering, it is quite possible for the way the browser formats a date to be different than the way it parses the date.
My issue is more with outputs than inputs (although the latter are also annoying to me in 12-hour format).
Operating systems generally allow user override of locale settings, and browsers generally respect that; I use a locale which officially has 12 hour time as its standard (Australian English), and I always override it to 24 hour time in user preferences (although Australia is rather inconsistent, e.g. in Sydney, train services use 24 hour time; in Melbourne, the metro trains use 12 hour time but the regional services use 24 hour time)
Interesting, so you're saying that that OS-level time preference is available via JavaScript? I wasn't able to figure out how to query that in a little bit of trying, so I assumed there was no API for it.
If there actually is, I'm now even more upset at that log web UI.
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.
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
and dates will format, but currencies, addresses, etc will not> That is the correct and only sane way to determine date format, timezone is not the same as formatting preference.
That's unfortunate, but then wouldn't the sane way for localization-aware software be to ask the user and not make any such assumptions?
> 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.
Thanks, I'll give that a try tomorrow! If my log exploring UI of, well, not quite choice actually respects that, I'll be very grateful :)
In a way it is asking the user. Date formatting rules are traditionally tied to locale, so the user picks their locale and their expected date formatting rules are derived from that.
On Linux you can mix and match via LC_*= environmental variables, but that appears to be complexity the browser vendors didn't expose in their UI.
Just a strong hint your fellow techdorks were being at work. Oh so clever, aren't they, always?
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.
> 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.
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?
Doesn't the JVM handle this when you set the tz? Otherwise...how is it different than just setting a clock?
> 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.
What about that one hour in the day when the date isn't the same?
You probably aren't working that hour. (also way better than 8).
And the computer isn't doing anything interesting during that time? You're reading logs, not using the computer as a clock.
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...
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.
Sure... "I'm too busy fighting fires to come up with a solution" is always a valid answer, but that's not what I was replying to.
Even with infinite resources (love to see that in real companies!), any such solution adds complexity, which comes at a cost.
If this is a complexity battle, I'd rather that sysadmins have to use a tool to read logs vs. figuring out why the server is melting down because all the jobs are running 2x or answering questions about why jobs didn't run at all.
In my old gig, jobs ran for many many HOURS and consumed most of the IO on the server (processing reams of data), which meant that when you got them running 2x because of overlap, it was a trainwreck.
In my experience, it's really not pleasant having to work with logs that require a dedicated viewer compared to regular old text files I can use Unix commands available everywhere (`tail`, `head`, `wc` etc), with, i.e. not just on the server producing the logs, but also the device I'm viewing them on.
That said, I absolutely prefer UTC times in logfiles. I'd rather do some math every time than make wrong assumptions about the local timezone of the file even once. (Even correctly indicated local times are more annoying, since I have the math for the offset of my timezone to UTC memorized, but not that of every possible server time to mine.)
alias tail="my fancy log viewer tail wrapper"
https://thecasualcoder.github.io/tztail/
That's exactly the type of thing I like to avoid having to do on some remote server, inside a container's minimal shell etc.
If you're at that level, I'd be exporting the logs anyway.
Yup. There's always some kind of tool anyway so why not. I mean, even if you read the logs as they come out of a screaming line printer, the tool is the thing that takes log messages and spits them out the printer port.
How hard can it be to write a log cat utility in awk?
Harder than not having to, in any case.
I mean, if this doesn't depict modern devops, I don't know what does. Unsung heroes, honestly.
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.
If you'd rather the logs be consistent, then log to UTC.
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.
> Computers can do things. Build a UX [...]
That sounds like a job for a human (at least the review part), not only a computer.
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.
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.
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. ;)
> most people expected your servers to be in Pacific or Eastern time
I was there back then, working for shops people have heard of, and I honestly don't know where you're getting this idea from. Some places did things wild and wacky when they were wee small, but most of us quickly learned that such shenanigans (like fun server naming conventions) start to fall apart and maybe we should do things differently.
Using UTC for servers was standard when I entered the field in 2005.
I was setting them to UTC in 1995.
Ah you think UTC is your ally? You merely adopted UTC. I was born in it, molded by it. I didn't see DST until I was already a man, by then it was nothing to me but blinding!
In the 1980s, PT and ET were common. I was working at Bell Labs then, and one of my jobs was to change the time zone (back then it was two words) on the testing machines, as needed. This is stuck in my memory since to change the timezone, you needed to edit the Unix kernel source code and recompile it!
2000 for me. That was the first time I had users from outside my own time zone, so I figured it was better to just use UTC for everything and just convert depending on the user's settings. I think I just applied the thinking to the whole server.
This is the way.
I run into this a lot when working with legacy code. The first reaction most teams have is to mock it, not understand it.
Yelp servers were set to Pacific time when I started in 2009, probably a decision from 2004
Everybody's dunking on you here but yeah, circa 18 years ago I remember that setting servers to local time was still pretty common.
It only matters if the servers were running cron jobs where it mattered if they ran "not at all or 2x."
Logs with weird dates on high demand production servers... less important.
Can you please make your substantive points without swipes? This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html.
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.
I believe it was an anecdote and not a recommendation.
Sounds like it was smart at the time, and then eventually outgrew the solution.
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.
"revisit it in the future" is exactly the reason your TODO list keeps growing rather than shrinking
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.
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.
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
And then with distributed team you realize DST change dates are different around the globe.
Expense a Rolex GMT Master or Sky Dweller. Tell your boss I said it was necessary!
Perhaps a shell alias for:
TZ="Etc/UTC" xclock -analog -update 1 -norender -hl grey -fg grey -bg black
(or similar) would also suffice.
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.
I do the same! I am in PDT and keep a UTC and EDT clock (most of my team is east coast)
One of the great things about living at 0 latitude is it's UTC half the year
Did you mean longitude?
I really love this idea!
"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.
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.
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.
> 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.
That sounds a bit like reimplementing a scheduler inside the scheduled task (which is ok if you don't trust your scheduler, but I'd avoid it if at all possible).
Except downtime can start during execution. So for many types of jobs...
- Check if run today, exiting on "yes"
- Run
- Update the last-run-on date
What is "today"?
Hopefully just a datetime recent enough that the job does not currently need to be (re-)run.
But as soon as one job needs another to complete first, or two jobs shouldn't be run at the same time - things start getting messy.
> Hopefully just a datetime recent enough that the job does not currently need to be (re-)run.
I can think of several ways to mess that seemingly trivial calculation up just from the top of my head. (Consider changing timezones, increasing the interval the job is running to within half a day of scheduling period etc.)
> "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.
Really depends on your market and customers. Especially in the financial industry, local time zones (often of a given currency's central bank's main branch, a primary regulator etc.) are often very, very entrenched.
> Many people will accept UTC because it is the international standard.
I really wish that were true universally...
And I do think that UTC is actually somewhat Eurocentric! From personal experience, it's significantly easier to mentally add/subtract one or two hours (modulo 24) than 7 or more.
> 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.
Definitely, but on the other hand, I do think that picking your head office's time zone as the "canonical" one for resetting quotas etc. has some merit as well, if only because it makes the concepts of "today" and "tomorrow" work a bit better. (UTC midnight might be very unintuitive to both you and your customers.)
> Definitely, but on the other hand, I do think that picking your head office's time zone as the "canonical"
What happens when you move your head office to a different time zone? e.g. Oracle moved their HQ from California to Texas (and have announced a further move to Tennessee, although last I heard that still hasn’t happened)
What happens when an M&A happens and you are now part of a much larger enterprise with a different HQ timezone, and systems with wildly inconsistent configured timezones due to having acquired multiple companies which had HQs in different time zones and all of which configured everything to use their HQ time?
> UTC midnight might be very unintuitive to both you and your customers
I live in eastern Australia, UTC+11 at the moment (UTC+10 during Southern Hemisphere winter). Right now, resetting stuff at UTC midnight means at 11am my time, resetting stuff at US Eastern midnight means at 3pm my time - roughly equal in potential inconvenience, but I’ll be much more forgiving of the first than the second.
> And I do think that UTC is actually somewhat Eurocentric! From personal experience, it's significantly easier to mentally add/subtract one or two hours (modulo 24) than 7 or more.
For me, add/subtract 10 is pretty easy… and then just one more during DST. Does that make UTC “Australia-centric”? Or Guam-centric or Vladivostok-centric? (both of which are also UTC+10)
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.
That doesn't fix the problem of "my quota reset (or reporting job) gets shifted by 1 hr when daylight saving time changes".
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. This is exactly what I said above.
That works if all your consumers of the report are indifferent to it arriving at a different time half of the year.
All of yours might well be, but you can't generalize that assumption to every domain and scenario.
If you want an email of the report to send out at 9am locally. Generate before and send to everyone based on timezone.
> Generate before and send to everyone based on timezone.
How are you going to do this? Clearly cron (with timezone set to UTC) doesn't work for this so you'll need another system. In that case why not have that multi-time zone scheduling system run your script?
You don’t want a report to include 25h or 23h twice a year just to be able to send it at some distinct local time.
I absolutely want some daily business reports to cover 25 hours on one day of the year and 23 on another, since that's how long a calendar day is in local time in every place that has DST shifts.
The report can run at whatever time you want it to run at. But this solution solves the issue of the report running 2x or not at all.
> That doesn't fix the problem of "my quota reset (or reporting job) gets shifted by 1 hr when daylight saving time changes".
How hard is to convert the UTC time to user's local time and perform quota reset?
I mean you should be doing this anyway. Even if you store everything in PST or EST or CST, you never know when you'll get customers from another part of the world and then you'll have to do this anyway. So why not do this already?
>Even if you store everything in PST or EST or CST, you never know when you'll get customers from another part of the world and then you'll have to do this anyway. So why not do this already?
1. allowing users to change their timezone and tying it to when their quota reset sounds like a great way to add more edge cases and complexity. For instance, does messing with your time zone mean you can get your quota reset multiple times a day?
2. Not everyone operates some sort of global b2c SaaS that's timezone agnostic. For many enterprise backoffice tasks "6am HQ time" is far more reasonable than "6am/7am, dunno depends on whether daylight saving time is on or not". In this case having a server set to the HQ's timezone makes far more sense than doing UTC and trying to work around daylight saving issues.
> How hard is to convert the UTC time to user's local time and perform quota reset?
Probably roughly as hard as writing a timezone-aware scheduler that considers all edge cases around daylight savings time, i.e. probably possible but I'd try fairly hard to see if I can get around it.
One way of getting around it is to run your batch jobs in your "primary business timezone". Sure, you might outgrow that concept eventually, but many companies never do, and in that sense "running on UTC" seems similarly aspirational in spirit (albeit at a much smaller scale) to starting with high scalability.
You could have the reset script check the timezone of the user before actually performing the reset, and have this script run at least once an hour to make sure you get close to accurate for most people (some timezones only differ by less than an hour though!).
But also, if the user can change the timezone themselves, now you have a condition where the user could keep their quota at bay for a very long time (if not forever) if they keep changing their timezone accordingly.
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.
> 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.
Hard math. Ah right, I think it's not till the third year of a mathematics degree that you deal with "subtracting 8"! :)
Don't forget changing the day 1/3 of the time. But more importantly, if I'm scrambling to solve an incident, the last thing I want to do is deal with time conversions in my head.
You just do it once and think in UTC going forward. But as I said to the other person, if you're only dealing with one timezone it's fine, just when you have multiple it's a lot easier to just deal with one time and let everyone convert.
I'd expect everyone who works in computer related jobs to know their UTC offset.
I'm able to subtract 8, but if I'm scanning logs it's one more thing to process.
If it's local time I know instantly when something happened, without having to do mental math.
Is there anything wrong with ISO8601 (including timezone offset) for storing times? They're in my local time, but they can be accurately converted to any other timezone.
No problem as long as it's all local, but it's a big annoyance to the other teams if I'm trying to coordinate with the West US team who're on PT, the East coast on ET, Europe on CET, India on IST, Australia on BBQ...
It's just easier for everyone if we agree on UTC and everyone knows their own offset.
Technical debt. Please don’t.
Yeah. I log in json + unix timestamp nanoseconds, and just convert it to something human-readable on display (github.com/jrockway/json-logs). I am not sure why logs need to be "pretty" at time of logging when they can be made pretty at time of display. Doing it at time of display means you can just use local time, and then nobody is confused.
Who hurt you? Why are you following me around begging people to use UTC?
> Who hurt you?
Nobody hurt them. Please don't do this kind of childish rebuttals. It looks really silly on HN. If you don't want to use UTC, that's one thing. You do you. But there are reasons for sane professionals (who weren't hurt by anybody) to expect their coworkers to use UTC when possible. Because using local timezone leads to some problems including the one in TFA.
Well me, I have been burned by fixing this UTC bug at like 8 companies and overall more than four year of my life (between other things, each project took at least six months of people poking at things) because at an eventual scaling point it starts biting your ass everywhere in every service.
Just because it worked once doesn't mean it's good.
I find all the holier-than-thou UTC worship especially ironic given that this post is about recurring scheduled tasks, for which naïve UTC almost never provides the expected results
UTC is the right choice for representing specific moments in time (so yes, log timestamps) but there are so many pitfalls outside of that narrow use case
Why not just store everything utc but add a local time to the logging along with it?
Nowadays you could probably pull that off, most tools support quickly changing the time on the fly.
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.
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?
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."
So I have to manually update the job
How about I use some form of library to do it. I tell it I want to run at 0800 London time, and it runs at 0800 London time
If I tell it I want to run at 0130 London time (or 0330 Athens time) I still have a problem -- do I run it twice when the clocks go back, do I skip it when clocks go forward?
But that's a business logic problem, and defining it as UTC and having another job to update the time twice a year doesn't actually solve the question of "what do I do at this point".
Generate earlier and send to various timezones when needed.
You don't have any choice in the matter. If you control the time you want the jobs to run externally from the server, then you can have control over it. Otherwise, you're getting jobs that run 2x or not at all.
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.
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.
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
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...
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
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?
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.
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.
All of Europe changes from 02:00 to 03:00
Better to think of it that it changes at 01:00 UTC, which takes care of the parts of Europe that are 2 or 3 hours ahead (instead of CET's 1 or 2), and the UK going "forward at 1 and back at 2"
"Europe DST changes at 01:00 UTC" - much simpler ;)
There are TZ rules that do all sorts of wild things.
Leading to my favourite web comic of all time.
https://www.monkeyuser.com/2018/going-global/
Monkey User is always entertaining.
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
Jon Postel, the original RFC Editor and IANA: https://www.rfc-editor.org/rfc/rfc2468
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.
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
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)
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".
With enough precision in your timestamp, you can base-10 encode arbitrary binary data and shove it in your nanos for debugging.
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.
To incrementally improve that tactic, systemd has RandomizedDelaySec, which is a convenient way to reduce the possibility of scheduling conflicts.
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.
One trick for cron is to prepend the actual command in the crontab with something like
which will delay it by 0 to 59 minutes at random.> 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?
> 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
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.
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.
I call this "rake stomping", as long as you're running back and forth in the same places every time, you'll never notice.
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.
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.
> Alternatively, where possible set the server timezone to UTC so that no daylight savings changes will happen at all
this is the way
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)
It appears that busybox cron is smart enough to handle it and only ran the jobs once.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."
https://github.com/mirror/busybox/blob/master/miscutils/cron...
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.
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.
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..
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.
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!
It depends on tz. 4 am in some countries too
DST is such a dumb mechanism anyway
just use UTC
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.
bruh, just use UTC
Ugh gross. Same non monotonic time problems just not every year.
TAI4LYFE!
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.
This post is literally about an issue observed in vixie-cron (as included in some distro c. 2013), not about any systemd implementation.
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.
Which cron is actual cron? There are tons of implementations out there.
This post describes vixie-cron, not systemd-timers.
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.
How does actual cron handle this situation?
"Not a problem" as in these only run these cron job once per day, irrespective of DST changes making a given "hour happen twice"?