Posted by pera 1 day ago
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.
> 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]
GP was proposing year-round standard time, not year-round DST.
I miss the humble SOX lamp to be honest, they made night look like night rather than a poor approximation of day. They also had benefits for wildlife, much of which is insensitive to the 589 nm wavelength as well as astronomy where the light is easily filtered out.
Arizona observes year-round Standard Time:
* https://en.wikipedia.org/wiki/Time_in_Arizona
Most legislation seems to be proposing year-round Daylight Saving Time, e.g.,
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.
> France has year round DST and an hour on top during summer
That's a weird way of putting it, but sure. Spain is also famous for their absurdly "late" schedules (e.g. dinner at 11pm). People will naturally adjust if the baseline is offset like that. France does as well, but to a lesser degree. Importantly, both countries still observe the shift twice a year, because having a DST shift is actually popular (at high latitudes; obviously it makes no sense in the tropics).
In 2019, the European Sleep Research Society (ESRS), the European Biological Rhythms Society (EBRS), and the Society for Research on Biological Rhythms (SRBR) wrote a joint statement to the European Commission advocating for permanent establishment of a more natural time.
* https://esrs.eu/wp-content/uploads/2019/03/To_the_EU_Commiss...
This would mean France and Spain being in UTC/GMT, and (most of) Portugal being in UTC-1.
The logic would be sound however. Social Jetlag is real. I for one loath DST and switching back to CET noticably improves my sleep and overall well being.
No, the more I think about this, PROGRAMMERS will HATE this.
I genuinely dont care if we pickstandard time” or “savings time” … i just want my year-round circadian rhythm to not get fucked up twice a year - it takes me so long to get used to the new one and then it gets rug pulled again.
You would wreak unmeasurable havoc across the target country.
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.
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.
Obligatory link to 2015's "So You Want To Abolish Time Zones":
* https://news.ycombinator.com/item?id=39692011
Way back in my pre-parent days, I used to wake up around noon, roll into work between 1-2 PM, work until around 10 PM, and then go to bed around 4:00 AM. There was briefly a proposal to give me and a few other late-rising coworkers rollback privileges to the Google Maps codebase, because between the Maps team in Zurich, the Maps team in Sydney, the Maps team in NYC, and a few night-owls in California, that would give them 24 hour coverage with significant overlap for handoffs. It went nowhere because we didn't work on Google Maps and some VP probably balked at having people not in their org with full owners privileges, but it's an interesting example of combining timezones + personal schedules to get better time coverage.
Lol. Lmao, even.
No further comment needed.
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.
many people prefer to have the daylight at the start of their day.
Therefore why not just stick to summertime and skip the whole "change every opening hours" thingy ?
Cities closer to the poles might want to adjust more than one hour, or none at all since they see little sunlight for months anyway. Cities near the equator might not need to adjust at all. Businesses that need to be synchronized could still coordinate their operating hours. It's the most natural approach is DST had never existed.
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. ;)
See 15 U.S.C. §§ 260a & 263 (https://www.law.cornell.edu/uscode/text/15/chapter-6/subchap...).
Even more pedantically, “standard time” is not necessarily consistent across each zone (particularly, during the period for which in parts of the zone it is advanced by an hour) since "standard time” only advances for those states, or parts of states, for which an exemption is not in place.
So, the Unix-y convention of using PST for "Pacific Standard Time without advancement", and PDT for "Pacific Standard Time with advancement" is the simplest way of getting meaningful concise labels out of the US legal scheme. (This is only a theoretical issue for some US timezones, but it is a concrete one for at least the Pacific and Hawaii-Aleutian Time Zones.)
I can't find a source (including 15 U.S.C. § 260a) that supports this reading, although I agree it's a little ambiguous. The law suggests that a region that doesn't observe DST is observing "the standard time otherwise applicable during that period" and is exempt from the provisions regarding advancement, not that "Pacific standard time" depends on where you are (see 15 U.S.C. § 263).
> So, the Unix-y convention [] is the simplest way
No argument there!
From 15 USD § 260a, right after laying out the baseline rule for advancing standard time: “... however, (1) any State that lies entirely within one time zone may by law exempt itself from the provisions of this subsection providing for the advancement of time, but only if that law provides that the entire State (including all political subdivisions thereof) shall observe the standard time otherwise applicable during that period, and (2) any State with parts thereof in more than one time zone may by law exempt either the entire State as provided in (1) or may exempt the entire area of the State lying within any time zone.”
There are places that are exempt from the legal rule advancing standard time, hence, in those places, standard time does not advance.
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.
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.
oh, yes, I got that mixed up. That also mean permanent winter time would be better for the sleep not permanent summer times (it was whatever the "standard" time was as far as I remember). Either way people cant decide on what time they prefer makes any change harder.
> I'm convinced it's the best of only bad options.
idk. the time switch every year comes with an increase in traffic accidents for up to a weak after it happens. While most jobs today either aren't overly dependent on sunlight anymore or don't sync up with e.g. start of school or similar anyway (e.g. field work). I guess that argument does differ for any area widely dominated by farming and limited farming automation.
It’s never been about farmers and never will be.
- you don't care about the clock but some time relative to sunrise
- aren't dependent on sunlight on your job anymore
- anyway have to head out very early before sunrise (for most of the year)
sure maybe DST does save a small bit of electric bill in some jobs, but thanks to modern light technology it's not really that relevant anymore, on the other hand the reliable increase in traffic accidents every time we switch to summer time does matter.
Now there still is the argument about what is healthier (ignoring the known unhealthy switching times) but there is so much with way stronger effects in modern life (e.g. TVs, bright white LED lamps etc.) that I'm not sure if the effect if even realistically measurable.
Don't ask what people living in the high altitudes will do - I'm still working on that.
It is sunrise you want to anchor it to, because it is sunrise that our circadian rhythms sync to.
You meant latitudes?
> At the equator, the position directly underneath the mean Sun travels west at about 463 metres per second. That means a standard rack unit is about one millisecond wide. At latitudes closer to the poles, the effect is amplified, although but not by more than an order of magnitude in the realistically habitable parts of the world.
Even a row of servers would all have different times.
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.
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.
You still learn that x time is your time to do y, and people will quickly adapt to whatever number x happens to have.
We only associate 9am with anything because we learned to. We could just as easily learn a different number, and people with different work schedules do just that.
If you say "9pm local time", everyone knows it's the evening no matter if it's the time you go to bed or stand up because you work the night shift.
If a book says someone slept until 1pm you now they slept until mid day, no mater where the story plays. You don't have to go to the internet and look up if where he lives 1pm is morning, evening, night, etc.
That’s quite a range to sync to. At least syncing to noon, you don’t get much shifting throughout the year since sunset and sunrise shift roughly equally.
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.
However, if it were somehow up to me, I’d would prefer a single global metric time.
One way or the other I don't think we'll make a big shift in timekeeping until/if we ever have a sizable population off Earth. Of course, that introduces its own time problems we don't have to deal with as much all being so close together :).
They’d be the same exact list. “offset +9 hours”- the only semantic difference would be that clocks don’t change.
I should mention that I spent a little bit of time in Saudi Arabia and expecting them to be out and about at 7pm like in Western Europe and the USA is crazy, they seem to get up later and keep going until 3am. I’ve never seen rush hour at 3am until I spent time in Riyadh. It’s a false construct we’ve decided on: that everyone follows the same time pattern anyway.
Why do we believe the world needs to wake up at 7am? If nothing else its so incredibly arbitrary to begin with.
But DST affects us exactly because people tried to standardise on time AND then shift that meaning twice a year. If we ditched timezones, then businesses could say ok we will work from 1700 until until 0100 or whatever, based on time relative to sunrise, it it would be consistent all year round.
The thing is, regardless of timezones, you have to ask people what times they work or are available or whatever. Also consider that timezones are arbitrary and made up anyway: china physically spans the space of 3 timezones yet the entire country uses one timezone.
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.
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.
I think this summarizes it. The negative effects are concentrated around the transition. The positive effects are spread throughout the year. You lose 1.44% life satisfaction for a few days, and gain immeasurably more over the course of the year.
PS: by late risers I of course mean people with shifted circadian clock, and not "lazy" people, like they are sometimes presented.
Whether sunrise is at 3am or 4am, you still basically need to have a way to sleep with unreasonable amounts of sunlight (eg 18-20 hour days).
At lower latitudes, summer time makes more sense because the difference between a 5am and 6am sunrise goes from "too early" to "manageable". Same goes for 9am being too late compared to 8am in the winter for example.
At higher latitudes, you have to accommodate no matter what.
At lower latitudes, 1h makes a difference.
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...
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.
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.
Please stick with utc across the board people, someone someday may have to clean up your mess.
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.
One is not necessarily and in all instances less of a mess to clean up behind than the other.
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.
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.
The server does not "know" anything about the time, that is, it's really about the sysadmin knowing what happened and when.
for example, I've got a server in my garage that runs Home Assistant. the overall server timezone is set to UTC, but I've configured Home Assistant with my "real" timezone so that I can define automation rules based on my local time.
Home Assistant also knows my GPS coordinates so that it can fetch weather, fire automation rules based on sunrise/sunset, etc. that wouldn't be possible with only the timezone.
https://docs.python.org/3/library/datetime.html#aware-and-na...
Yes, that's exactly what I'm saying :). In fact, I've run servers where I didn't even physically know where it was located. It wouldn't have been hard to find out given some digging with traceroute, but it didn't matter. It was something I could SSH into and do everything I needed to without caring where it was.
Everyone else down-thread has clarified the why of it. Keep all of your globally distributed assets all running on a common clock (UTC) so that you can readily correlate things that have happened between them (and the rest of the world) without having to do a bunch of timezone math all the time.
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.
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.
I asked the HTML spec editors to fix this, but thus far they haven’t: https://github.com/whatwg/html/issues/6698
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.
If there actually is, I'm now even more upset at that log web UI.
Intl.DateTimeFormat([],{"timeStyle":"medium"}).format(new Date())
By contrast, this should return it formatted with the defaults for your locale, ignoring your user preferences:
Intl.DateTimeFormat(navigator.language,{"timeStyle":"medium"}).format(new Date())
I know the same works on Windows, and I’m sure it works on Linux too, just the way you configure it is different for each OS.
It does not for me! (I get 12 hour based time in Safari, Firefox, and Chrome, despite having 24 hours configured at the macOS system level.)
A plus would be showing both.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
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
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 :)
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.
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.
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.
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.
https://unix.stackexchange.com/questions/274816/how-to-conve...
Timezones are naturally complex. They just are. If you're not handling it, then your stuff is broken.
Of course all stored timestamps should include a timezone (assuming there's a local context to the events they refer to) if at all possible. I hope that part is not controversial.
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.
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.)
How hard can it be to write a log cat utility in awk?
That sounds like a job for a human (at least the review part), not only a computer.
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. ;)
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.
Logs with weird dates on high demand production servers... less important.
Company went bust before it got fixed.
Just use UTC folks unless you have a really good idea why you shouldn't.
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
$ zdump -Vc 2025,2026 America/New_York
America/New_York Sun Mar 9 06:59:59 2025 UT = Sun Mar 9 01:59:59 2025 EST isdst=0 gmtoff=-18000
America/New_York Sun Mar 9 07:00:00 2025 UT = Sun Mar 9 03:00:00 2025 EDT isdst=1 gmtoff=-14400
America/New_York Sun Nov 2 05:59:59 2025 UT = Sun Nov 2 01:59:59 2025 EDT isdst=1 gmtoff=-14400
America/New_York Sun Nov 2 06:00:00 2025 UT = Sun Nov 2 01:00:00 2025 EST isdst=0 gmtoff=-18000
$ zdump -Vc 2025,2026 Europe/London
Europe/London Sun Mar 30 00:59:59 2025 UT = Sun Mar 30 00:59:59 2025 GMT isdst=0 gmtoff=0
Europe/London Sun Mar 30 01:00:00 2025 UT = Sun Mar 30 02:00:00 2025 BST isdst=1 gmtoff=3600
Europe/London Sun Oct 26 00:59:59 2025 UT = Sun Oct 26 01:59:59 2025 BST isdst=1 gmtoff=3600
Europe/London Sun Oct 26 01:00:00 2025 UT = Sun Oct 26 01:00:00 2025 GMT isdst=0 gmtoff=0TZ="Etc/UTC" xclock -analog -update 1 -norender -hl grey -fg grey -bg black
(or similar) would also suffice.
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.
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 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).
- Check if run today, exiting on "yes"
- Run
- Update the last-run-on date
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.
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.)
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.
> 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.)
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.
Instead of tying your quotas to calendar days in some specific time zone, tie them to a rolling 24 hour usage period. Even better: use a rolling hour.
All of yours might well be, but you can't generalize that assumption to every domain and scenario.
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?
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?
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.
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.
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.
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.
> 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?
If the business requires it to run at 01:30 and there are two per day, or zero per day, then the business rules needs to define what happens. You can't solve this by running it at UTC.
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."
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".
This isn't a problem that can be solved with a single technical solution.
Just found out some guy decided to try to restart the company. Good luck. https://x.com/Austen/status/1981904435539280324
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.
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
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.
Just because it worked once doesn't mean it's good.
I'd expect everyone who works in computer related jobs to know their UTC offset.
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.
It's just easier for everyone if we agree on UTC and everyone knows their own offset.
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?
My guess is that in the US they do the same but shifted by one.
"Europe DST changes at 01:00 UTC" - much simpler ;)
https://www.monkeyuser.com/2018/going-global/
Monkey User is always entertaining.
https://en.wikipedia.org/wiki/Ramadan#Beginning https://en.wikipedia.org/wiki/Date_of_Easter
I wonder how on earth do you deal with a 30 or 45 minute offset in real life
https://www.sciencealert.com/daylight-savings-time-change-ki...
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
Debian's fork is still based on vixie-cron, but it couldn't have been the one because of the aforementioned patch.
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)
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...
This combines very simple configuration, while being predictable and spreading out timers well.
sleep $(( $(od -N1 -tuC -An /dev/urandom) % 60 ))m ;
0 2 * * * run-parts /etc/periodic/daily
0 3 * * 6 run-parts /etc/periodic/weekly
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."