Timezone Bullshit | Hacker News Reader

Timezone Bullshit

blog.wesleyac.com

400 pointsorganian319 comments

Another reason not to use EST/EDT is that they are overspecifying the time zone in most cases. If you ask for output in EDT, but the date is in December (which is not part of daylight savings time) then should the date output be UTC-4 or UTC-5? Technically you asked for EDT.

Using EST as a shortcut isn’t a good idea, either - most software will “know what you mean” and use EST or EDT appropriately... except, both The USA and Canada have been toying with the idea of dropping daylight savings time, so it’s very possible at some point in the future that 6:00pm on July 1st will be EDT in America/New York, but EST in America/Montreal (or vice versa). This is already true for CST - Saskatchewan doesn’t use DST. And there have been times where one country or another changes the start date or end date of DST too, so there’s no reason to assume those will always be the same between Canada and the US.

On the topic of DST... can you explain why some countries use DST? Anytime I look for the reasoning of it, it says that DST helps "make better use of daytime" but how? The earth isn't gonna say "Damn! These people changed their clocks. I better change by rotation and give them more sun time." Whether you have DST or not, you still have the same amount of time with sunlight in a day.

The closer one is to the poles, the more the number of hours of daylight shifts over the seasons.

So at/near the equator, in a place like Panama, you will get roughly 12 hours of daylight in both the December and June Solstices.

* https://www.timeanddate.com/sun/panama/panama

Whereas in the Edinburgh you go from having 7 hours of daylight in December to over 17 hours in June:

* https://www.timeanddate.com/sun/uk/edinburgh

So people want those 7 hours to be when it's most convenient for them.

The goal makes sense but our current DST implementation of a sixty-minute jump twice a year seems unnecessarily large and disruptive. (And not just dealing with kids -- traffic accidents and heart attacks spike after.) Whereas if there was a way to coordinate a daily shift it would be less than a minute.

It reminds me of when I'm camping. I usually fall into a dawn-based time system: Wake up around ~dawn, eat breakfast ~d+2h, lunch ~d+6h, dinner ~d+12h, bed down ~d+16h. You maximize daylight this way but the main problem is that you end up drifting relative to everyone else and if you want to rely on a standard watch to keep your schedule it requires some mental math.

I'd love to figure out how to use a combination of dawn-based time system for my daily routines plus UTC for remote collaboration.

It's a technology path dependence issue.

When towns had public mechanical clocks they were typically frequently adjusted (even daily) so that noon was when the sun was directly overhead.

Once railroads were developed their schedules were a mess since each time had to be in the time of the specific station. So the railroads got time zones introduced.

Then when the move for DST came around it had to be something easy to calculate, thus a one hour shift. Sort of like the Dow Jones: something that could be easily calculated by hand.

The infuriating thing is that our solution to this is to change the clock instead of just changing our schedules. It's completely ridiculous.

...no, actually it’s extremely logical. Changing clocks society wide is far easier than getting every single person and company to adjust its schedule.

>than getting every single person and company to adjust its schedule

but by using DST we are just pretending that we didn't ask people/companies to adjust their schedules. in reality they did, just the "clock" stayed the same.

Exactly. Changing our clocks is changing our schedules, the easy way.

Yes, it is similar to how creating inflation by the government is just a way to tax poor and the middle class, without actually rising taxes.

Wrong. Inflation is a way to tax lenders, and reward debtors who get to repay their debts with less valuable currency. As the poor and middle class are more likely to be net debtors, they tend to benefit from inflation.

Perhaps it was easier in the times before the internet. Now a consistent timeline should be far more convenient than not having to change your habits by a little bit.

Edit: If changing schedule is normalized, then it would be just as convenient as changing the clock. In countries without DST, if someone started using DST instead of changing their own schedule, it would be just as difficult.

I don’t think anyone other than programmers thinks DST is much of an inconvenience. The clock changes twice a year, big deal. That’s infinitely less complicated than asking your boss if you can start earlier, which means the store at the subway station will need to be open an hour earlier (since its business comes from commuters), which means restaurants will need to be open earlier to address the lunch crowd, which means your doctor will need to schedule appointments earlier, on and on.

In all fairness, people like parents with young children, pets, etc. find time changes disruptive. That said, there are good reasons to shift schedules in mid latitudes and daylight saving time is a good way to do that if you don't want 4am sunrises in the summer or heading out in the pitch black in the winter.

The reality is that if you don't do daylight savings, you're not going to have a collective switch in schedules and you're going to have to deal with what, for most, is sub-optimal sunlight.

Personally, I don't care much now because I mostly set my own schedule. But I'd have hated eliminating daylight savings when I was on a more fixed schedule.

> I don’t think anyone other than programmers thinks DST is much of an inconvenience.

I don't think anyone other than programmers thinks DST is not a huge pain in the ass.

Twice a year your bodyclock gets screwed up and you risk getting to work at the wrong time; once a year you even get a shorter night of sleep.

In Europe (hardly "programmer's country"), it took very simple polling to discover that DST was hugely unpopular. The population at large simply does not benefit, it was introduced for the good of industry and we're largely leaving behind that world. Good riddance.

> I don’t think anyone other than programmers thinks DST is much of an inconvenience. The clock changes twice a year, big deal

Everyone, and I mean everyone, I talk to about DST hates DST and wants it gone. It's definitely not just programmers who dislike it.

I think it's hugely inconvenient, I have to shift my waking and sleeping time by an hour twice a year and it takes at least a week to settle into the new schedule, and I have at least a half dozen clocks to shift time on, including one that needs a ladder.

Without DST why would I need to ask my boss to start an hour earlier? I've lived in places without DST and it was just fine, I didn't notice or miss any "extra" hour of daylight.

Your argument sounds very similar to the "let's abolish timezones" argument so let me post this again: https://qntm.org/abolish

Changing your schedule works for you and your boss, but does not let people in other parts of the world know when they can reach you. Officially shifting something is necessary, and then you might as well have timezones.

I find it insane that there are otherwise-smart people in the world that want to abolish time zones. For example, this NY Times article. [1]

In includes the most bizarre history:

> A century and a half ago, time zones didn’t exist. They were a consequence of the invention of railroads.

... and goes on to describe that it's suddenly so confusing and laughable that when it was 7:00 in New York, it would now be 8:00 in Chicago and 5:00 in San Francisco.

But what on Earth did the writer think the time was in San Francisco before there were time zones?

Before there were time zones, everyone synchronized to local noon. The result was much more fine-grained "time zones." What time zones did was to actually flatten those difference, leading to fewer time zones, because now suddenly the time in Maine was the same as the time in Michigan, despite being at completely different longitudes.

1. https://www.nytimes.com/2016/11/06/opinion/sunday/time-to-du...

> The result was much more fine-grained "time zones."

That is true, but it did not bother anyone, because fast long-distance communication either did not exist or was very limited (e.g. smoke signals) and syncing of clocks wasn't necessary in everyday activities; for a medieval person, the idea that clocks in Vienna and Prague MUST be synchronized would be as strange as for us the idea that everyone in the same city should have their breakfast at the same time. It just did not serve any obvious purpose.

There are only two exceptions I can think of.

a) people doing astrological horoscopes for someone who was born in a different place (a big thing among some nobility and royalty) would probably be bothered a bit by the time difference,

b) armies trying to converge on the same target at the same moment.

Some extended timezone databases even have tried to collect historic city timezones from before the railroads, most often to the nearest 15 minute offset, but sometimes even minute specific offsets. It's interesting to explore those.

On that Michigan versus Maine thing, as someone in a city that historically was -0045 from its current timezone, I feel it interesting to point out that DST is closer to local noon than "Standard Time" in the city, versus that cities that define the other edge of the time zone and have local noon closer to Standard Time noon. (Our hour-wide time zones make the question of DST versus Standard Time much more complex than just picking one or the other, when talking about abolishing DST or standardizing only on DST.)

For some evidence of this, consider that sundials have existed since about 1500 BCE. The existence of such a device easily disproves the notion that the "current time" was ever the same globally. Even mechanical clocks would obviously need to be set such that they would agree with a sundial, or the reading of the mechanical clock would be useless in a world where others are using sundials.

It's a while since I read that article, so I may forget some details, but I do recall that I found it pretty stupid. It somehow assumes that it would be harder to find out what the regular working hours are in a country are than it is to find out what time it is in that country, possibly in addition to what the regular working hours are.

If Google today tells me, "It's now 5PM in Singapore", with no time zones it could just as easily tell me "Regular working hours in Singapore are 12-20".

OK, so that's two numbers to remember rather than one, but come on. Thing is, what a certain time means varies wildly country to country, and from person to person anyway. My Swedish friends eat dinner at 17:30. My friends in southern Europe eat dinner at ~22:00.

Unless I know who I'm calling, and their regular hours I have no idea if it's OK to give them a call at, say, 07:00 or 22:00. So I need extra information about them anyway - and that information wouldn't be harder to package in a world lacking time zones. In fact, it would be easier, since it'd contain only one element (times available) rather than two (times available plus timezone).

I read it last time. I still think it's a weak argument, and that abolishing time zones has benefits that outweigh its costs.

People in other parts of the world can reach me at any time by email, during the work hours of the email server.

It's even easier post-internet. Your clocks automatically change for you now. In the past you had to remember when the change occurred and updated all your clocks manually - and if you forgot you ended up an hour late/early to any Sunday appointment after the change.

What's this inconvenience you're talking about? I often don't even realize when daylight savings changes because everything is automatic. My alarm wakes me up at the new correct time, the clocks on my phone and computer have adjusted themselves. Sometimes I wonder why the clock on the oven is wrong and then Google to find out that daylight savings just happened. Maybe some people have more dependence on non-internet-connected clocks or work through the night on Sunday?

Easier to get a few computers to automatically change their clock twice a year than every human being to change their schedule.

This. Coordinating a mass schedule change is just an alternate implementation of a time shift.

The primary benefit of mass schedule change is that it might make (some) programmers' lives easier. The disadvantage is that it makes everyone else's lives harder as they adapt to schedule shifts.

(Clocks exist to serve people, people don't exist to serve clocks.)

We shouldn't even adjust our schedules. We should just accept the fact that it is going to be dark at different times.

Then again, this would be an issue for road workers (those who repair highways or other roads) and maybe trash collection services. So it begins... Horrible.

Technically DST _is_ accepting that it's going to be dark at different times, and therefore the completely man-made thing that is a clock can be changed a bit to reflect that.

A perfectly human solution really: work around the shift in daylight hours across the year by fiddling with the clocks. The whole thing with schedules and timetables is a self inflicted problem in a post-industrial society, sure, but workarounds are never really meant to be more than a bandaid.

The problem is that you need to "fiddle with the clocks" in a coordinated way. Schools can't shift around starting times asynchronously with the many businesses where parents work for example.

Yeah. Any sufficiently coordinated schedule change would involve as much headache as clock changes.

No, the worst is that date outputs wrong data without error. Wrong input is silently ignored, and the output 3 letter code is also wrong. Bug report pending

Times get written down or otherwise recorded, it would be a lot of work to update or duplicate entries for opening hours on signs and websites, times in laws, and various other things to account for the time of year. Instead we can just update the clock and have all the references preserved.

The worst thing is that the farther north you go, the less it matters. In Ireland, DST only really makes a difference for a month or so around the change. In the summer, light. In the winter, dark.

DST mostly matters between about 35-50 degrees latitude. Less than that and the days are similar enough in length throughout the year that it doesn't really make sense to change clocks. And, as you say, much further north (or south) you have more light than you know what to do with in the summer and you're probably largely in darkness outside of work hours in the winter whatever fiddling you do.

> So people want those 7 hours to be when it's most convenient for them.

In theory. Going by the normal justification for daylight savings, the convenient hours to have sun are the afternoon. But if that was it, then you'd expect the clock to be pushed even further in the winter.

It's actually the other way around. DST is applied in summer, so people actually want those 17 hours when it's convenient :)

..and the latitude where that 17 hours finally grows to 24 is called the Arctic Circle.

Golf courses. Well, okay, this is my wonderful father's half serious answer that I love to retell.

The basic idea is that it's easier to convince everyone that is actually 5:00pm and time to leave work than it is to convince just your boss that you want to start work an hour earlier and leave and hour earlier.

This problem is then applied to politicians and other powerful people, who want to go golfing after work. If there's no DST, the sun will set "earlier" according to the clock, and you can't get in a full 18 holes.

So therefore, we change all the clocks so that powerful rich people can go golfing.

No other group of people sees any benefits to DST.

>So therefore, we change all the clocks so that powerful rich people can go golfing.

>No other group of people sees any benefits to DST.

Ah yes, because only powerful rich people would benefit from extra time in the evening to do outdoor activities.

I didn't say it was right, just that I love it.

But truthfully, if our society wants more time in daylight after work... let's just leave work earlier. I mean, we are doing that, we're just changing the clocks and pretending we aren't. It's dumb.

Since 2018, 13 states in the US passed resolutions to get rid of the semi-annual clock changes but also that daylight saving time become permanent. Of course, federal law doesn’t allow them to do such (a state only has the option to not observe DST, but not the option to permanently observe it).

It probably depends somewhat on latitude and longitude, I for one would prefer year round daylight saving time as I like the extra evening light in the summer and it’s dark when my kids leave for school in the winter anyway. I don’t golf.

The idea of shifting working hours to account for the season changes might work in some contexts but not others. Sure, if I’m an office “information worker” it’s probably not a big deal to shift to 7-4 in the summer. But I don’t think that’s going to work for retail, grocery, post office, restaurants, gyms, pharmacies, etc. where the public isn’t going want to constantly adjust to and guess at changing opening and closing times.

But the public does adjust to changing opening and closing times.

We just all change the clocks as well and pretend that we didn't. And it's stupid.

The previous discussion was talking about adjusting work hours as an alternative to daylight saving time. My comment is that’s not viable a alternative as I don’t think people want to try to determine if the post office closes at 4:00 or 5:00 depending on the date. Additionally, if everyone shifts working hours based on the time of year, how is that different than just changing the clock?

My point is not for or against daylight saving time, just that shifting work hours is not a viable alternative to it. And if we do get rid of changing clocks, there’s a decent chunk of the population that has expressed a preference for permanent daylight saving time rather than standard time.

It’s worth nothing that in Russia they experimented with permanent daylight time some years ago, and at first it was highly supported. However, after some years support for it dropped and they moved to permanent standard time. However, Russia deals with some unique geographical scenarios such as cities with extreme northern latitudes.

I don't know what you mean by "pretend we didn't". We don't pretend anything - we change the clocks and observe that change.

> a state only has the option to not observe DST, but not the option to permanently observe it

Do state have the option to change their timezone altogether?

Permanent DST is the same as shifting one tz over and not having DST and this would make more sense.

Are there really places that don't observe DST and also don't change their working hours? Just shift the working hours by a few hours when the seasons change. It also gives more granularity for the changes. If 1 week in the whole season is particularly cold, then change the time again for that 1 week.

That sounds like a huge coordination problem. Those problems are usually solved by some central entity enacting a standard, i.e. government enacting DST.

I assumed this was the norm in places that don't observe DST? Your workday is 9-5, year round, no we're not considering the time the sun sets

> Are there really places that don't observe DST and also don't change their working hours?

Huh? I'll flip the question around on you: What places are there that don't observe DST that do change working hours seasonally, especially in a coordinated way? I haven't heard of any.

The liquor store I worked in in Australia had longer hours in summer than winter.

Pools and parks have longer opening hours in summer than winter too. That's not really the same thing as DST though; it's orthogonal.

> Are there really places that don't observe DST and also don't change their working hours?

Yes, literally every state/province in North America that doesn't observe DST. I don't know what goes on in Europe, but nobody in Arizona for example changes the open/close time of their barbershop, restaurant, or gas station solely due to the time the sun rises...

Even with DST here we still have "winter hours" for many businesses where it doesn't make sense to be open late (10 PM in summer is still light out, 10 PM in winter, sun set 5-6 hours ago).

The golf courses are closed when it's too dark, but the offices aren't. You need to close the office a few hours before the golf course, even if your office business isn't strongly dependent on the amount of daylight.

Arizona

Do Arizona banks and post offices and stuff really change their hours in different seasons?

Nope. There really isn't much reason to. The winters are mild, and Arizona is far enough south that there's still a good amount of daylight in the afternoons, at least compared to the northern parts of the US.

I suspect that at least some of disconnect over DST is between people living at 40-50 degrees latitude who have short winter days and those living further south.

Normally they match winter sunrise and keep it fixed all year long.

I like DST and I'm neither rich nor a politician. I could be wrong, but I think farmers in general would be pro DST.

Farmers are the most hurt by it.

Farmers need to work on daylight. They can't change their schedule when the clocks change. So during half the year, the busy half, all the business start closing down an hour early.

You got a bunch of longish replies to your question and I can't tell if they covered the simple answer. DST changes the question of : is it dark at 7am when I get up or not? is it light when I get off work at 5 or not?

It aims to shift the usable daylight hours to correspond with human activity.

It's interesting how it's easier to change time than to change the hours in which we work. I wonder if there's any country where the government has enough control over working hours to shift those around instead. Instead of shifting the clock one hour, we could shift the time we start and end work.

It's like DST is the wrong solution to an XY problem.

Thinking practically though, DST is bound to work without enforcement, so it has that advantage.

It's interesting how it's easier to change time than to change the hours in which we work.

What with covid/wfh, I have been wondering is this might be the push needed to end DST. Because I sure as hell have changed the time I work. Dog walk in the dark in December because about 4 hours of daylight in Seattle? Fuck that, we walk the dogs smack in the middle of the day now, we can work when it's dark. Strap on the reflective gear, headlamp, and go for a run? Oh, hell no. 2 in the afternoon, baby; I'll fix that bug late afternoon.

I still get up super early, but instead of getting in that run before work, I just work. Then shift that running time to when the sun's up. But I speak from the position of the privileged tech worker (and one w/o a lot of meetings). There are still the DST issues of when children stand waiting for the school bus, et. al.

> It's interesting how it's easier to change time than to change the hours in which we work.

I think the main pain point would be customers being confused as to when companies are open.

This doesn't even work well with smartphones; all the calendar apps are hopelessly manual and can't answer something like "what are good times to run an errand involving steps X, Y, Z."

At best, you can ask it when people are available for a meeting and it will show you that everyone important is booked solid.

> I think the main pain point would be customers being confused as to when companies are open.

But why would so many people rely on a 1 hour difference that this would become a "main pain point"? I don't know the working hours of most places I go to. When I really want to know, I check Google Maps (or their website). Even then, when it's close to opening or closing hours by like an hour, I sometimes prefer not to trust it if it'd be too problematic for it to be closed after making the trip, because it does happen at times that it's incorrect. Small shops might not even follow their own stamped-on-the-window working hours strictly either.

I'd be interested to hear the experience of people in China. As I understand it, all of China shares a single timezone while neighbors to the north and south are spread across five timezones.

Clocks in western China are four hours out of sync with their neighbors just over the southern border in Pakistan, for example. So do businesses in western China open from 1pm to 9pm? Do people eat breakfast at noon?

I'm really curious about that experience.

https://www.theatlantic.com/china/archive/2013/11/china-only...

I think one practicality of it that you forget is the difficulty for people too, not just for businesses or government entities.

For example, people are used to banks always being open 9am to 5pm. With the approach you mentioned, it means that twice a year they will have to shift it. It means you will also have to shift your entire schedule, and calendar, and literally everything. Now think about some shops and places that will NOT be switching it and decide to keep the same hours. Then add-in the fact that some shops already change their hours even with the current system. For example, I have a daily recurring alarm for 7am. Under this proposed system, I will have to manually change it twice a year (while now it is done automatically due to the entire timezone switching twice a year).

You will simply get a logistical nightmare, since changing the entire clock is much much simpler than shifting each individual little scheduled item in your life.

Tl;dr: while i agree that logically your approach of shifting individual scheduling items to align with the daylight hours makes more logical sense, it makes more practical sense to just switch timezones twice a year for that purpose.

> I have a daily recurring alarm for 7am. Under this proposed system, I will have to manually change it twice a year (while now it is done automatically due to the entire timezone switching twice a year). You will simply get a logistical nightmare

At least with respect to updating the alarm, that "logistical nightmare" can't be any worse than what we had before clocks updated themselves. I still remember having to update all clocks manually twice a year. It wasn't a big deal. Someone coming in late or missing an appointment because they forgot to update a clock happened rarely. Maybe it's not the case now, but you used to get multiple warnings reminding you to update your clocks.

> For example, people are used to banks always being open 9am to 5pm. With the approach you mentioned, it means that twice a year they will have to shift it. It means you will also have to shift your entire schedule, and calendar, and literally everything.

With respect to opening and closing hours of banks and shops, for those few people that go near opening or closing hours even in that time of the year, they'll make the mistake that day and either come back later when it's open or otherwise fix their issue that day or at least they won't make the same mistake the next day. The world wouldn't go up in flames because of this.

> It's interesting how it's easier to change time than to change the hours in which we work. I wonder if there's any country where the government has enough control over working hours to shift those around instead. Instead of shifting the clock one hour, we could shift the time we start and end work.

Iran used to do that. But for some reason they abandoned it and now use "normal" daylight saving time.

Indian offices, schools, shops do this. Although I don't think its by government order, it is just the it is always. Almost every timings psoster show winter/summer times.

>It aims to shift the usable daylight hours to correspond with human activity.

But it fails miserably at it.. Here in NYS all winter long it gets dark at 5PM. Summer, 9PM.

It's useless and just causes inevitable confusion every year.

There’s nothing to be done about winter, that is the “regular” time and you live in the north. You only get the sun above the horizon for 9 hours a day in late December.

The summer 9pm is the advantage of daylight savings. You get the sun up for 15 hours a day! Norther summer is great. Without daylight savings time, you’d get dark at 8pm in the summer and have an hour of “wasted” daylight before you got up. The “savings” part is to take the wasted light while you are sleeping and move it to the evening when you can enjoy it.

It does cause confusion though, and having implemented daylight savings code there are a bewildering number of rules around the world, there are even places that have double daylight savings. They shift once, then shift again for a two hour offset.

I appreciate the response and explanation, I guess I was mistaken on which direction DST was being used for! All my life I was under the assumption that it was the other way around, to try and get back more time during the winter. Thinking about it more now though, that doesn't even make sense given the direction the clock changes..

I'm still not sure it is worth the confusion it causes but I do have a better understanding of why it exists now. Thank you!

I love the extra hour of daylight in summer evenings and anytime I'm anywhere where it gets darker early in the summer I feel like I'm giving up part of the fun of my life.

I still don't get it. During the winter, the daylight hour is literally shorter, not just shifted. Shifting one hour won't magically make it longer. At best it gives your more daylight in one end, while sacrificing the other (and more than 1 hour, since again, the total daylight hour is shorter). So why bother?

Because the idea is that sunlight during a particular part of the day is more valuable. One reason I've seen given (not saying I agree with it) is that if you "move" the sunlight to the morning, it means kids won't have to wait for the school bus in the dark. Or if you "move" it to the afternoon, then there will be a little bit of daylight at the end of the day for people working 9-5, which might be useful if you want to go for a run or something.

Just once I’d like to have a time zone discussion on HN that doesn’t devolve into pages of arguing about daylight saving time.

If you search HN you’ll find plenty on this topic.

You'll have a happier life if your dreams are attainable.

I mean, you're not wrong... but what else is there to talk about?

Fact of the matter is, your preferences depend on where you live, your lifestyle, and the amount of time you spend on date&time fuckery in code. It's a contentious issue.

I am from India, northern part, where there is a lotbof variation between sunlight hours throughout the year. Some days the sun is out at 6 or before in summer, & in winter its some time not out even till 9 or such.

India does not use timezones. Every business, school, office who has business hours, use something like Winter Timings Summer Timings. Schools & such use 14 Oct to 14 Apr as Winter, & other 6 months as summer. My school used to open at 6 in summers, & 7:30 or 8 in winters.

Here in US they keep the opening timings same throughout the year, but go through this DST shenanigans.

For the same reason that work from home turns out to be viable for a huge number of people, and the main reason office's are as big as they are is because middle managers don't believe work happens if they don't watch someone sit in an office chair.

There's no possible way businesses are going to adjust their hours twice yearly to let employees get more sunshine, but DST does that effectively by ensuring official timekeeping gets moved about on them.

The even dirtier secret is that NOBODY KNOWS if work is getting done because often the work is pointless or ill-defined.

What is the point of sunshine if you sit in a box all day? You get equally zero amount of it during summer as well as winter.

> Whether you have DST or not, you still have the same amount of time with sunlight in a day

Yes, but you can better align the available light with things like commutes and school hours - so that people commute in light instead of the dark, for example.

We need to get rid of DST switches permanently. We should stick with DST as most people prefer extra light at night.

Because of the unfortunately still common 9-to-5 work schedule.

The excuse usually given is to match up farm work, which is dictated by dawn, with general work shift patterns.

However, I recall that farmers are very split on the issue when polled - it impacts on their work shifts as well.

Source: none, this is my pure supposition and projection.

Power. The sensation of raw power.

By and large, the best way to eliminate DST would be for one or more sufficiently powerful lawmakers or political executives to say: this is no longer benefiting the public at large, and we are going to stop!

These are the folks empowered to change the date on which DST transitions (at least stateside). These are also the same folks whose careers have been mostly defined by the deliberate and incremental accumulation of power into their own hands.

If you're wired for that kind of desire for power, the ability to tell the entire country: okay, I am changing time! It happens on this date! --must be simply _irresistible_. I mean: you're literally changing TIME. Hot shit! The entire population has to respond! You're changing TIME! Why give that up?

While I'm storytelling and presuming, I'll note that this needn't be a deliberate, conscious decision; I'm only suggesting that the people positioned to change this sort of thing are probably naturally wired to resist doing so, and may not even be aware of why themselves.

I (living in California) usually use "PST8PDT", which does what I want, all year round (for some irrational reason I refuse to claim that I live in Los_Angeles[0]). I believe there's also "EST5EDT", "CST6CDT", and "MST7MDT" as well.

But agree that this is just a grab bag of confusing garbage.

[0] I suppose if CA does away with DST (or keeps it permanently), I will have to change...

Huh, your LA note prompted me to say “That’s why I use US/Pacific”. But someone on the internet tells me I’ve been doing it wrong and US/Pacific has been deprecated for years / I’m not supposed to:

https://stackoverflow.com/questions/4309030/difference-betwe...

> toying with the idea of dropping daylight

Europeans turn back clocks for daylight saving, perhaps for last time. source: https://www.dw.com/en/europeans-turn-back-clocks-for-dayligh...

The EU DST debacle has been such a shitshow that I have trouble believing the words "perhaps for last time". And now with COVID-19, I haven't seen anyone actually focus on implementing the damn thing.

What do you have to implement?

For once pretty much no one is aware of this supposed change. There was like a couple of articles on the day it was voted and that's it.

This will 100% not happen, it's another one of those things that the EU parliament votes that everyone ignores, and it's perfect ammunition for those complaining that it makes laws without popular consultation.

Trying to go forward with this change will generate massive anti EU backlash.

And then you have the UK problem. Having variable time offsets between EU and UK would add yet another layer of disruption on top of Brexit.

>it makes laws without popular consultation

That's not accurate.

>This online consultation, which ran from 4 July to 16 August 2018, received 4.6 million responses from all 28 Member States, the highest number of responses ever received in any Commission public consultation. According to the preliminary results (see annex), 84% of respondents are in favour of putting an end to the bi-annual clock change.

Selection effect. Those who really cared about this commented.

But what about the 99% rest of population? It's a mistake thinking that because they dont realllly care they will accept either way.

Resistance to change is huge, especially when it plays into the narrative "Bruxelles demanded it"

And what I meant by lack of popular consultation is that if you go on EU streets and ask about this change 95% of people will have no idea what you are talking about.

> Selection effect. Those who really cared about this commented.

And a disproportionate proportion of those (more than two thirds) were from Germany, were that topic was an especially hot issue for some reason or other.

No representative democracy is asking the electorate to vote on each and every bill. It defeats the purpose of having a parliament in the first place.

I agree with you.

I was just pointing out that it's wrong to say this this decision had ample consultation, because overwhelmingly the population is not aware of it.

In other words, an internet poll in which less than 1% of the population participated, 2/3 of which were from Germany.

>> And then you have the UK problem. Having variable time offsets between EU and UK would add yet another layer of disruption on top of Brexit.

It's worse than just EU/UK offset. You would have Northern Ireland and the Republic of Ireland in different timezones.

Portugal and Spain manage it, but it would be extremely contentius among around half of the NI community.

Issues with the NI/IE border are always delicate, due to obvious reasons in the recent past. Let's say Portugal and Spain's quarrels are much much farther in the past!

> For once pretty much no one is aware of this supposed change

The consultation had 4.6 million responses.

> Having variable time offsets between EU and UK would add yet another layer of disruption on top of Brexit.

So?

> The consultation had 4.6 million responses.

A disproportionate amount of which were from Germany (2/3 of the responses, even though Germany only is only ~ 16 % of the EU-population pre-Brexit).

The EU is currently one timezone for most of its area, the whole continent excluding Portugal (edit: and Finland, Greece, Baltic states) has the same timezone. But actually it should be 3 or 4 timezones if you want to be close to solar time. Also, there are people who would prefer having solar zone time +1 (so e.g. UTC+2 in Germany instead of UTC+1). The EU decided to chicken out and let the members decide for themselves. So now each country has to decide which timezone it would like to implement, and of course if a neighbour does it differently, you also got yourself a timezone boundary at your border, which people dislike. So now all the politicians are caught in a state of indecision, keeping the status quo.

>The EU is currently one timezone for most of its area, the whole continent excluding Portugal has the same timezone.

That's definitely not accurate.

A good portion of the EU is in CET when they probably shouldn't be when it comes to solar time:

* https://en.wikipedia.org/wiki/Time_in_Europe

France should probably, AFAICT, be in WET (like the UK) and Spain definitely should be. Solar time offsets are quite off for them:

* http://blog.poormansmath.net/how-much-is-time-wrong-around-t...

* https://github.com/stefano-maggiolo/solar-time-vs-standard-t...

* https://24timezones.com/world-time-zones#toc-0

I hope that we can stop trying to sync noon to the local sun at some point. I think it made sense when communicating over distances was hard and rare. In that case giving local time some meaning (ex: "People tend to wake up around 8") had some value. However now that communicating with people around the word is commonplace I think that benefit is outweighed by the value of knowing what time people are talking about. Because if you try to schedule something before I want to wake up it is incredibly obvious to me. However if we mess up the timezone math by and hour no one will notice unless they think to explicitly check.

The only real downside I see is that if the day number changes during your "day" it could be confusing. However I think we will quickly learn to deal with it (overnight shifts have been a thing forever and doctors seem to manage). Plus we already have a weaker form of this when we are talking about late-night activities so I think we will figure it out.

> I hope that we can stop trying to sync noon to the local sun at some point.

Humans have circadian rhythms that have health effects:

* https://en.wikipedia.org/wiki/Chronobiology

See my comment linking to various position papers of the scientists who study in this field:

* https://news.ycombinator.com/item?id=26088541

They generally want to get rid of DST completely and stick with Standard ("winter") Time all year round. (I don't know enough to gainsay them.)

Oh, you are right, sorry. The Baltic states, Finland and Greece are UTC+2/3

IE use DST also fyi.

> The EU decided to chicken out and let the members decide for themselves

There are reasons the EU doesn't just enforce timeZones across its members.. So this is a 'strange' comment that bothered me.

I didn't mean to say the EU should enforce a timezone. The EU didn't get involved at all after the decision to get rid of DST. Not even by providing guidance or suggestions for the new timezone layout. Usually when there is something to be decided, there is a EU summit or work group. But they didn't even do that.

Brazil spent 3 years talking to everybody, publishing the change, and making sure everybody was on the same page. Yet, all the companies providing software got it wrong at least once (some more than 3 times). The only software that got it right were community based FOSS distributions (not raspbmc... that got me).

At least all the institutions got it right, so it was enough to announce "Windows|Red Hat|iOS|Android|whatever is wrong today, ignore it and use some other clock".

It will not happen. The science is overwhelming that having one timezone all year long is worse for people, and switching the clock back and forth twice a years is a minor nuisance at most.

The EU's "Ban DST" is the same populist bullshit as Trumps "inject Windex to cure COVID". Based on nothing and ignorant at best.

And the cherry on top is, if you ask the EU if they want to receive a no strings attached gift of €10.000.000.000.000 or €11.000.000.000.000, it would still take them 20 years to decide. No way they will ever reach consensus on DST.

If the science is overwhelming, do you have a source? If not, what are the downsides to having the same timezone all year?

[Some links that I've posted the last few times DST has come up:]

The folks who study this:

* https://en.wikipedia.org/wiki/Chronobiology

Seem to have come to a consensus that if we're going to get rid of DST, then health-wise it is best to have Standard Time year-round:

> As an international organization of scientists dedicated to studying circadian and other biological rhythms, the Society for Research on Biological Rhythms (SRBR) engaged experts in the field to write a Position Paper on the consequences of choosing to live on DST or Standard Time (ST). The authors take the position that, based on comparisons of large populations living in DST or ST or on western versus eastern edges of time zones, the advantages of permanent ST outweigh switching to DST annually or permanently.

* https://journals.sagepub.com/doi/full/10.1177/07487304198541...

For a longer-read, referencing quite a bit of academic literature, but a conclusionary snippet:

> In summary, the scientific literature strongly argues against the switching between DST and Standard Time and even more so against adopting DST permanently. The latter would exaggerate all the effects described above /beyond/ the simple extension of DST from approximately 8 months/year to 12 months/year (depending on country) since /body clocks/ are generally even later during winter than during the long photoperiods of summer (with DST) (Kantermann et al., 2007; Hadlow et al., 2014, 2018; Hashizaki et al., 2018). Perennial DST increases SJL prevalence even more, as described above.

* https://www.frontiersin.org/articles/10.3389/fphys.2019.0094...

Other position papers that I've dug up over the years when curiosity got the better of me:

> Society for Research on Biological Rhythms (SRBR) is dedicated to advancing rigorous, peer-reviewed science and evidence-based policies related to sleep and circadian biology.

* https://srbr.org/advocacy/daylight-saving-time-presskit/

* (refs, with pro and con): https://srbr.org/wp-content/uploads/2020/09/DST-References-S...

European Sleep Research Society:

* https://esrs.eu/wp-content/uploads/2019/03/To_the_EU_Commiss...

Canadian Society for Chronobiology:

* https://www.theglobeandmail.com/opinion/article-turn-back-th...

* https://twitter.com/ChronobioCanada/status/11906320965969264...

American Academy of Sleep Medicine (with 36 footnotes if you want to dig further):

* https://jcsm.aasm.org/doi/10.5664/jcsm.8780

* https://doi.org/10.5664/jcsm.8780

The Centre for Chronobiology, based at the Psychiatric University Hospital (University of Basel):

* http://www.chronobiology.ch/wp-content/uploads/2019/08/JBR-D...

* http://www.chronobiology.ch

(Personally, I'm just going to trust the experts on this as I don't have the energy to go digging in things. A quick cursory Google/DDG search is enough for me.)

The sun rises in Singapore between 0655 and 0715 depending on the time of the year. How would changing the clock help at all?

It wouldn't, as it gets ~12 hours at both solstices:

* https://www.timeanddate.com/sun/singapore/singapore

DST is mostly for countries closer to the poles. See my other comment:

* https://news.ycombinator.com/item?id=26088383

Never heard about windex. Now I know.

> The science is overwhelming that having one timezone all year long is worse for people,

Well the majority of people, countries, and square-kilometres of land doesn't have daylight saving so you'll have to do better than that.

At some latitudes with some social norms (regarding things like school start times) DST is beneficial. In others it's not. There are no absolutes here.

> If you ask for output in EDT, but the date is in December (which is not part of daylight savings time) then should the date output be UTC-4 or UTC-5?

EST is always UTC-4 and EDT is always UTC-5. Both of these exist throughout the year. The only change happening in Spring/Autumn is that some places change which time zone they currently observe.

This also addresses the second problem that you outlined. As long as the query is properly specified (if you want information related to a location, use America/New York; if you want information related to a time zone, use the time zone), you can always get an unambiguous and correct answer.

To be pedantic EST and EDT are offsets. America/New_York is the timezone which consists of multiple offsets that depends on the time of year and date mostly determined by the local civil authority. For example in 2005, the US extended daylight saving time by four weeks. This difference between 2004 and 2006 is a part of the timezone.

Cool, I hadn't realized that distinction in terminology. Thanks for pointing it out! :)

> EST is always UTC-4 and EDT is always UTC-5.

Except you have those reversed. :)

< EST is always UTC-4

Unfortunately not. Australia also used EST until recently. Now they've introduced AEST, but I'm sure there's systems out there using EST.

When somebody writes EST in summer they mean UTC-4. Interpreting that as UTC-5 is almost always wrong.

Right, but that's because people are misinformed as to how timezones work. EST means UTC-5; people who refer to EST as current during the summer are incorrect. Most news outlets avoid the problem by just saying "ET" or "Eastern Time", which I wish more people would do.

> both The USA and Canada have been toying with the idea of dropping daylight savings time

Individual states are toying with the idea as well [1], which presents a problem if one of the tzdata locations decides to change its rules. You're screwed no matter what you choose to do. :-(

1: https://www.syracuse.com/state/2020/11/state-senator-introdu...

It gets worse: DST in Indiana has to be handled on a per-county basis for anything prior to 2006.

https://en.m.wikipedia.org/wiki/Time_in_Indiana

It gets worse: from when I had to deal with this some years back IIRC in Saudi Arabia the start and end of DST is set by decree every year.

They already do. See Arizona.

…and then see Navajo reservation in there, and then see the Hopi reservation inside of that!

I just always write ET, PT, MT, CT.

The only situation where our datetime instances deal with timezones is on a one way trip to a user's display, document or email. If you are playing around with parsing timezone strings, you are probably making a huge mistake unless you are parsing someone else's trash data.

I feel the standard interchange format for datetimes really should be 64 bit Unix timestamps. These are trivial to store in any database as a native type, can be compared using the fastest arithmetic instructions possible, and are a locale agnostic representation suitable for direct business logic comparisons.

Trying to carry timezone information around is a mistake. This is state that should be terminated and normalized at both ends, not passed through the system.

The only thing I would store pertaining to timezone is for user profile or server environment configuration. These would be settings in the application that are used to produce locale-specific UI and reports.

There are probably some other use cases I am not thinking of, but that is the extent of how we do it and we have a really complex app that has to serve customers who operate in multiple timezones at once.

Human-decided events in the future are an obvious example. E.g. "every second Tuesday at 8:00" or "May 17, 2025, 8:00" shouldn't ever happen at 7 or 9, even if your software didn't have accurate DST information for that point available initially (which countries do change, sometimes with only a few weeks of warning!).

What if you're scheduling a meeting for multiple people, and normally you're in Seattle, but for some of these meetings you'll be in New York? You don't want the meeting to be at 8:00 your time because chances are the people in Seattle aren't going to join your call at 5:00 their time.

As someone who routinely sets meetings for people in multiple timezones, let me say this isn't confusing.

All the calendaring tools I use or am aware of, at this point, keep up with time zone correctly (or have so far). I set the meeting for, say, 10 CST, and it's clear to my colleagues in Seattle that it will be 8 for them, just as it's clear for my coworkers in DC that it'll be 11.

There are still edge cases.

What if you schedule a meeting in a year's time in a timezone that doesn't have Daylight Savings Time but that government decides to add it and now the meeting is at a time that doesn't exist?

But your use case it also talking about when using a tool that is specifically designed to deal with this issue. What about when you are trying to find a good time (AFAIK most calendars don't have good tooling for collaboratively choosing a meeting time). If you do this in your favourite chat app then you probably have no timezone support. (This would be an awesome feature though)

Real calendar applications handle this by storing the scheduled time as GMT, and the UI adds an offset for where users are. This also solves the problem of you driving between time zones between the time that you schedule the meeting and the time that you attend it.

The problem is that the GMT time for a future event is unknowable. Timezones change based on the whims of governments. They change rarely, but they do change.

Your calendar can store the GMT time for lookups but it will need to recalculate this if the timezone data changes.

Furthermore it isn't as simple as "storing GMT" for repeating events. As the offset will be different for different occurrences. So you need to store the original timezone for the recurrence rule. (And see the above problem about the absolute time of a current local time being unknowable)

As far as I’m aware, GMT has never changed since the advent of computing.

Yes, you do need to store the location of the scheduler so that you can adjust everything as appropriate, and of course you need to schedule the time the event was created. But you still only store those times in GMT.

By the way, what I’m describing is the way every AWS system does it.

Edit : Oddly, I can’t reply to your reply to this, but I already addressed the case you were talking about in this comment.

The problem isn't that GMT changes, it is that the local time changes.

If I schedule an event in 1 year at 08:00 in MyCityTimezone and you store that the event occurs at 13:00 GMT then 3 months later MyCity decides that they aren't doing Daylight Savings Anymore your GMT time is now wrong. My event must still occur at 08:00 which is now 14:00 (or whatever) GMT.

"Just" storing it in GMT isn't enough. You probably do want to do that but you need to store the local time as well and update GMT to match if timezones change.

This is very frequently done wrong because timezones don't change often so the "Just store GMT" mostly works. But if you are writing a high quality system you need to deal with these cases.

Twice a year we have to deal with calendar screw-ups because a third of our employees are in a locale that doesn't observe DST and the rest are in locales that do observe it. If an employee from that first group sets up a recurring meeting, the meeting time changes for everyone else in March and November.

A meetings timezone can be independent of a users, yes. E.g. the meeting time should be specified as e.g. "8:00 America/Los_Angeles" (or have a location-based lookup, but thats another level of indirection). That way it follows whatever DST rules there are, but your local phone time being in NY time only affects your display.

> Trying to carry timezone information around is a mistake.

No.

If a human says a recurring meeting happens at 9 AM Pacific time and the following week they are in daylight saving time, it'll still happen at 9 AM local time. Preserving intent is crucial in this case.

Even better with "virtual meetings": 9AM in which user timezone? Sometime people move and they still expect the meeting to happen at 9am for them.

isn't that a local time and not a timestamp/datetime?

Sort of. If you expect to have to deal with people in other time zones, though, you still need to carry time zone information, so the person who lives in New York will correctly dial in to the meeting at their noon and not their 9am.

(This also raises the point that you need to preserve zone information, not just the UTC offset. Otherwise the meeting will move after a daylight saving time change, which is not usually what people want.)

It's not quite so cut-and-dry. UNIX timestamps unfortunately don't solve the problems of time because they don't contain enough information.

Time is something that developers get wrong more often than any other type. Your time data requirements change as your use case for the time changes.

From https://github.com/kstenerud/compact-time/blob/master/compac...

Aside from issues of synchronization, leap seconds, data container limitations and such, it's important to choose the correct kind of time to store, and the right kind depends on what the purpose of recording the time is.

There are three main kinds of time:

*Absolute Time*

Absolute time is a time that is fixed relative to UTC (or relative to an offset from UTC). It is not affected by daylight savings time, nor will it ever change if an area's time zone changes for political reasons. Absolute time is best recorded in the UTC time zone, and is mostly useful for events in the past (because the time zone is now fixed at the time of the event, so it probably no longer matters what specific time zone was in effect).

*Fixed Time*

Fixed time is a time that is fixed to a particular place, and that place has a time zone associated with it (but the time zone might change for political reasons in the future,for example with daylight savings). If the venue changes, only the time zone data needs to be updated. An example would be an appointment in London this coming October 12th at 10:30.

*Floating Time*

Floating (or local) time is always relative to the time zone of the observer. If you travel and change time zones, floating time changes zones with you. If you and another observer are in different time zones and observe the same floating time value, the absolute times you calculate will be different. An example would be your 8:00 morning workout.

*When to Use Each Kind*

Use whichever kind of time most succinctly and completely handles your time needs. Don't depend on time zone information as a proxy for a location; that's depending on a side effect, which is always brittle. Always store location information separately if it's important.

Examples:

Recording an event: Absolute

Log entries: Absolute

An appointment: Fixed

Your daily schedule: Floating

Deadlines: Usually fixed time, but possibly absolute time.

Interesting to see fixed and floating time differentiated. I didn't really have a name for that last concept.

And fixed time I would call local time. Why call it fixed? Because it's tied to a location?

I avoided "local" because the name could technically be claimed by both types: "It's called -local- because it's local to a particular zone" vs "It's called -local- because it's local to my current (local) zone."

So I went with floating vs fixed because it feels less prone to ambiguity. "Fixed" is fixed to a particular zone, and "floating" floats along with me as my current zone changes.

> I feel the standard interchange format for datetimes really should be 64 bit Unix timestamps.

Several people have already replied pointing out that for scheduling events in the future, particularly recurring events, it's practically necessary to refer to time zones.

So I'll just mention the problem of leap seconds, which are announced six months in advance. If a one-second error could cause problems then probably you should use TAI rather than UTC. But you still need UTC for other purposes, so probably you need both and so you need to keep track of whether a particular timestamp is TAI or UTC.

And then your application has to schedule a recurring weekly meeting happening at exactly 9:00 CST, and suddenly, you have to update your DB schema and all code instances everywhere to actually deal with the time zones. And then you realize you'd be better off if you were just using a sane time zone library from the start instead of pretending time zones don't exist.

They are different things.

You store your datetimes/instants as UTC, you store your "every day at 9 CST" rule separate from that.

Your rule table might have a column for a cron expression, and a column for the tz database name.

Meanwhile, your table for the meeting records has the time represented as a UTC timestamp.

And to stay with the theme of the article: Chances are, the meeting actually _isn't_ intended to be scheduled for 9am CST, but rather 9am America/Chicago. The key difference being that Chicago only observes CST for half of the year, and most people would probably expect for their recurring meeting to happen at the same local time, regardless of the season.

If the meeting is in _the other_ CST (the Taipei one), there's good news: Taipei doesn't do daylight savings. On the flip side, Chicago attendees might dial in fourteen hours early, so Asia/Taipei is a safer bet, too.

> I feel the standard interchange format for datetimes really should be 64 bit Unix timestamps.

UNIX timestamps are ambiguous.

ISO 8601 is perfectly good interchange format.

I agree with this, mostly.

Besides the "meeting time" exception others have mentioned, you should be aware of timezones when grouping records into days/weeks/months/years/etc. The timezone affects where you "cut" the continuum into groups. Does Joe's sale count toward his January quota or February? This has all kinds of interesting questions: do you use the user's time zone? The local office timezone? The HQ timezone? UTC for everything? What if the user moves? Stack Overflow's "fanatic" badge just uses UTC: https://stackoverflow.com/help/badges/83/fanatic

Other commenters are right, one article that lays out the case that there are plenty of times what you say isn't right: https://zachholman.com/talk/utc-is-enough-for-everyone-right.

Use UTC everywhere, then display in the user's timezone is a perfectly valid pattern...for specific use cases. Those use cases are very common, but many people over generalize, and assume that it can handle all cases.

Hmm, your applications don't have user input asking for a time?

We do have one case where we do have to capture the hour of day for an IT activity. In this situation, we present the UI in the timezone configured by the customer's server and additionally display this timezone information in the UI as reference/confirmation for the user. Once the user submits their input in terms of server-local time, we immediately convert it to UTC for storage in our system. Note that because we present the actual TZ info, this even supports servers that are already configured for UTC. We have no edge cases aside from ensuring our users pay attention to the TZ info.

I still don't understand the arguments about a future date requiring a timezone. UTC can 100% accurately represent a future date or event without any ambiguity. If a user, meeting or other aggregate has a culture/timezone preference, this is a completely separate business fact from the time.

> I still don't understand the arguments about a future date requiring a timezone.

A future event at local time requires a location, because the timezone may yet change at that location. Suppose we meet Nov 1st 2017 in Istanbul and decide to repeat this the year after. We agree to meet again Nov 1st 2018 in Istanbul 10:00 local time. This meeting would have been projected to happen at UTC 8:00, because Turkey was scheduled to switch to UTC+2 on October 30 2018.

However, the government decided to not change the timezone and stay on UTC+3. So our meeting, being scheduled for 10:00 local time, would move from UTC 8:00 to UTC 7:00 at the stroke of a pen. If your software had recorded UTC time, it would be ignorant of this change and consequently it would show the meeting at 11:00 local time. You'd be one hour late.

This change in the tz DB is a little window into the questionable cultural achievement that is local time: https://github.com/eggert/tz/commit/e15ef79a603a2fba89ad8f38...

> I still don't understand the arguments about a future date requiring a timezone.

It's not that a future date requires a time zone, you are right that can be 100% represented with a fixed timestamp. But there is the extreme case that time zone rules may change from the time you schedule the event to the time it happens, and in that case your event is now at the wrong time.

Consider the case where you have a weekly meeting at 9:00 AM on Tuesdays in an America/Chicago office. You could surely calculate the next N weeks of meetings and save them as UTC timestamps, taking into account that we shift into daylight savings time at some point, so you end up with a nice list of timestamps at 9:00 local time. But if the time zone rules change at any point (say, Chicago decides not to observe daylight savings time any more), now all of your meetings are an hour off.

If you had saved the meetings in a more verbose but true-to-intent format that properly captures "Every Tuesday at 9:00 AM America/Chicago", then at the time those rules changed you would either automatically have updated meeting timestamps, or some consolidation process could go and update the meeting times.

Even without sweeping changes like that, we still have unscheduled leap seconds, minutes, etc. every once in a while, which will also mess up your timestamps. I'm actually excited to see the day my calendar somehow ends up with a meeting at exactly 9:00:01.

The GUI elements should have nothing to do with storing and interchanging timestamps. What you display can query the browser timezone to make it look nice, then send it down converted, over.

Ding ding ding, we got a winner. No, absolutely do not query the timezone once then "convert" (aka remove) the information. Timezones change all the time.

And if the timezone changes, should the meeting you booked at 9 AM now happen at 8 AM?

There's a (fresh) extensive comment right above mine which explains the 4 different use cases for dates and the very minimal real need of TZ, let's all read it. Sorry I cannot comment otherwise your arguments because you didn't offer any.

You cannot convert a time string in the future to a timestamp. You must keep it as a string with timezone information until the time actually comes.

IMO depending on the use case, just the TZ info won't save you. Say I arrange a meeting for 4pm local time (where summer daylight savings time will be active) for July 2022.. and then the city I want to meet in gets invaded by a foreign army and changes its timezone. And cancels summer time. What time is my meeting now?

I guess it needs to be a 4-dimensional coordinate, where 1 axis can slide around...

You should store TZ info in the "Europe/Brussels" form, rather than "CET" or "UTC-1" which aren't easy to use anyway.

If a foreign army invades Belgium and changes its timezone, Europe/Brussels will get updated.

'There is no good reason to use short timezone codes like EST, CST, PST — doing so will only bring you pain. Either use the tzdb name like America/New_York, or use an offset from UTC, depending on what you want.'

All you need to read/remember is this, this applies everywhere not just with date.

The problem is peoples fascination with the S in the timezones, if you remove the S and the timezone equates to the proper, daylight savings adjusted +/- timezone according to the tz db. So instead of EST,CST,PST, use ET,CT,PT. For example ET equating to America/New_York, or as I prefer, US/Eastern. Traditional posix such as EST5EDT can have data gaps which cause issues that the tz db make up for, so in general:

Just use UTC for most things.

As with all things time, I'm no expert, and could be wrong about something. If you are, please correct me!

>As with all things time, I'm no expert, and could be wrong about something. If you are, please correct me!

Easy example that I have to deal with semi-regularly since I live and work in Mountain Time: Arizona. Arizona is under Mountain Time, but does not observe Daylight Savings. So America/Phoenix would work fine (and America/Denver for the rest of the Mountain Time zone) but simply using MT would not.

To complicate matters even more is that the Navajo reservation (which is partially in Arizona) observes DST, but the Hopi Reservation (also in Arizona, but completely surrounded by the Navajo Reservation) does not.

Unfortunately the statement is not true. One good reason to use short timezone codes like EST, CST, PST is that most people prefer them.

One of the first surprising things you learn after launching a timezone conversion website https://news.ycombinator.com/item?id=1133613 is that one of the top feature requests is to display short timezone codes.

And people prefer them because I have known since I was like 4 that I'm on Eastern time but have exactly zero idea what my UTC offset is off the top of my head. And also because I observe daylight savings EST changes automatically for me while I have to remember whether I'm in DST to know my UTC offset.

The problem highlighted here causes one of the few gripes I have with PostgreSQL, and its logging capabilities in particular: It seems to only support logging time in one single format, which does contain a timezone identifier - but using the potentially ambiguous shorthand name.

A few moons ago, that led me down a whole new rabbit hole of its own that is Golang's time zone parsing capabilities (https://github.com/golang/go/issues/9617), which, at least for Elastic's filebeat, seem to vary at runtime depending on whether or not you have a time zone database available...

Moral of the story: Please just conform to ISO-8601 everywhere.

I'd say the moral is that server side should always be in UTC.

In some cases, storing times in UTC opens you up to possible errors:

https://codeofmatt.com/on-the-timing-of-time-zone-changes/

I think the right thing is to store times with the timezone the user wanted when they created the time. You can often use defaults or other UX niceties to streamline specifying TZ, but not always.

Also, if you'll want to unambiguously know the timestamp's exact point in time at some point (like for comparison with other dayetimes), you should save the offset from UTC alongside the actual datetime. Otherwise, around clock changes like "fall back" you cannot tell if you're seeing 2 AM for the first or second time.

This is the best I've come to trying to piece datetime storage together. If someone has better advice, I'd love to hear it.

For more of my theory on timezone handling and the sources I've used to help me think it through, see http://howicode.nateeag.com/dates-and-times.html .

.NET's DatetimeOffset class does this really well, and what's nice is you can access the local system's timezone database to convert it to whatever the local time was in that timezone for a given date (it's aware of when DST or timezone changes occured). I'm sure several other languages have similar tools too.

It doesn't solve every conceivable timezone issue, but it solves 99% of the problems most developers would have with it.

Unless sub-second accuracy is required, I'd be in favour of UT1. It doesn't use SI seconds (while TAI and UTC do), but it has the advantage that a day has exactly 86400 seconds, so you don't ever have to deal with "23:59:60" timestamps.

Summary:

UT1 - noon is when the sun is above you, day has 86400 seconds (not SI seconds)

TAI - noon drifts away from when the sun is above you, day has 86400 SI seconds

UTC - noon is when the sun is above you (+/- 1 second), day has 86400+/-1 SI seconds

Difference UT1-TAI: continuously diverging

Difference UT1-UTC: continuously diverging up to less than +/-1 second, then discretely jumps back when it gets too big (leap seconds)

Difference TAI-UTC: increasing in discrete increments of +/-1 full second (leap seconds)

I'd rather just use TAI and never have to worry about anything. Let the conversion to UTC be the client's problem.

Having the length of a second always be the same is kind of important.

For logs, fine. But you do deviate more and more from what the world is using (as of 2017, TAI is exactly 37 seconds ahead of UTC, according to Wikipedia)

Not true. Say you want to save an event that you know will happen on the 14th of July at 15:00 Paris time, in the year 2025. Current time zone rules tells you this will be at 13:00 UTC. Well, if France decides to abolish DST and stick to standard time before then, you'll be wrong.

No, they won't be wrong, because the TZ database includes historical data & will know that DST was still in effect at the time you saved the timestamp.

[Ed. Nevermind, sorry, I see you're referring to a future point. My bad. You're right.]

For that use case definitely, though a law change is a bit of an edge case.

For stamping times like in a log though UTC should always be used server side.

Sure! But my point is there's no one true way to do it and you always have to think about what you're trying to represent and how you're going to use it.

Also, I would argue time manipulation is full of many "edge cases" like this one, which is why it's so hard. It's going to work fine until it doesn't.

OR.. should they be in TAI? https://en.wikipedia.org/wiki/International_Atomic_Time

Surprisingly, a bunch of software doesn't like it when you setup TAI, if you manage it to begin with.

I'm still hoping .beat time[1] will catch on but I have been waiting since 1998... I even made a watch-face for my smartwatch showing .beats

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

I'm guessing (from your name and enthusiasm) that you live in a place where 0 approximately corresponds to midnight? :)

It would be more fair to split a week into 6000 parts, that way everyone would have midnight at strange ”hours” but on different days.

Lunch at @500...

Another alternative is to base time on the current longitude of the solar meridian.

> There are actually two timezones that are canonically named "CST", and they're 14 hours apart!

Yup. If you say CST do you mean China Standard Time or Central Standard Time? The answer will depend on where you live in the world. There are others that share the same abbreviation as well. But CST is the one that constantly causes trouble in daily life. Just say no.

According to Wikipedia there are more than one overlappings: https://en.wikipedia.org/wiki/List_of_time_zone_abbreviation...

I think BST, CST and IST are the only triple overlaps. I live in one and I'm adjacent to another.

As a support engineer living in Dublin “IST” is the bane of my life.

I got bit by this when scheduling an interview. It's interesting because it's not that much harder to say America/Chicago (or just Chicago) but it's just by default I tend to say CST, CDT, etc. Started using UTC offsets but not many people know those off the top of their heads.

I find using the Olson DB names works in real life too--everybody understands "9AM Chicago" vs. "9AM Shanghai". Major international city names have fewer hash collisions than TZ abbreviations.

Many years ago USPS provided a data stream that included every sorting machine operation a mail piece went through, the location it occurred (zip code), and the local time (sans timezone information). That was an absolute nightmare of a project that always had a few weekly cases of letters somehow time-traveling. Also, I was surprised to learn that there are sort facilities on tribal lands - I was not surprised to learn that they elected to record time differently from the state that surrounded them.

On macOS (Catalina-10.15.7), it looks like it is fixed or uses an updated version of the libc library mentioned in the article

Expected:

$ TZ=LOL_THIS_DOESNT_EXIST date Sat 10 Jul 2021 12:00:00 AM LOL

Actual:

$ TZ=LOL_THIS_DOESNT_EXIST date Wed Feb 10 17:02:02 UTC 2021

Otherwise I agree with the article. Have told so many co-workers that storing your dates in anything other than UTC will bite you in the ass later on. Converting it to the relevant time zone for display purposes is a trivial operation.

It's not as simple as UTC everywhere. If you're representing a fixed point in time, independent of any local time, then yes. But sometimes, a date/time is relative to the local time zone and in those cases, the local time zone is the correct one to store it in. For example, scheduled times for future events in the real world such as appointments. You can't store it as UTC because you can't know what the time zone offset will be in the future since that's a political decision.

> Either use the tzdb name like America/New_York, or use an offset from UTC, depending on what you want.

I bet storing an offset is far more pain, given that anyone in a DST area will have 2 offsets per year.

Offsets can very easily be the wrong answer (though the author is quite correct that it depends on what you're trying to do). If your user intends to use one of the timezones that has a daylight savings calculation, the offset changes as the year goes on. Offsets can also change if the definition of the timezone itself changes (Russia ceased to use daylight savings in 2014).

Offsets can be useful if one is attempting to record a historical incident, where the timezone had a particular-defined offset at the point in time the incident occurred (though for my money, I'd just convert that time to UTC on storage).

This needs more upvotes.

The part about "using the text of the invalid timezone" seems to be fixed in latest GNU date (8.32):

  $ TZ=EDT gdate
  Wed Feb 10 13:22:23 UTC 2021
  $ gdate --version
  date (GNU coreutils) 8.32
  ...

8.30 (shipped in debian buster) still has the problem.

The BSD version of date shipped with MacOS 10.15 also does not seem to have this bug.

more likely the libc. I have the same version of GNU date using glibc and this behavior persists, as I would expect.

ah, that makes sense. Looks like the gdate I'm using only links against libsystem, and I don't have a glibc anywhere. So it's the darwin libc that doesn't have this bug.

Testing with https://hub.docker.com/_/busybox, it seems like musl also has this problem. uclibc is not affected.

> Let's take take a look, using the disastrously bad unix libc timezone tools

Are there any more examples of them causing issues to warrant being called "disastrously bad"? This post just seems to have one example of bad error handling when they the TZ env var is set incorrectly.

I'm genuinely interested if they actually are bad since they are used a lot.

They usually work because people check and notice mistakes.

It gets worse now that you have countries next to each other that are out of sync on daylight saving - America/Los Angeles doesn’t work for those south of the border anymore - but you won’t notice except two weeks a year.

Strangely I’ve noticed some systems give you WAY more cities than in the standard library - and I’m not sure why. Linode had way more options than just America/Chicago but didn’t have St Paul.

And trying to schedule things in advance across the daylight saving time difference is even more confusing.

Before about 1920, many US cities had their own time. Since then, there are far fewer time zones, mostly uniform across states, and named after a large city. Similarly in other countries. The large version of the database is only needed if you're trying to print very old dates.

Man, as a European this confuses the shit out of me. EST/CST and friends are nearly meaningless because I don't even know if the time I'm looking at is or supposed to be DST adjusted...

I work with a proprietary programming language that internally models a date_time as a UNIX epoch offset. The to_string method of a date_time results in a nice human readable string in the local timezone, but crucially not including the TZ itself. There were also accessors for the HH:MM:SS parts of the date_time.

At some point, the problem must've come up "if it's 5pm here in SFO, what time is it in MIA?", or some variation on that theme.

Someone decided that the best way to answer this was to write a function that took a date_time, then altered it to apply an offset between timezones. e.g. time_local_to_tz.

So you can could take a date_time in SFO, do time_local_to_tz (supplying Miami's TZ) and get back a date_time value that would to_string in SFO to show "the time in MIA". These functions made their way into a standard library and then to a lot of code.

The only problem is that the assumptions are literally all wrong. Adding the offset changes the actual point in time being addressed, which can change the timezone in effect in the current location, which results in the result skewing. This was compounded by some developers assuming that maybe they should convert their times to UTC before persisting them.

Of course, the usage of these functions is now embedded in a bunch of code no-one dares to touch, because it is full of hacks to "make it work" and quite possibly there is other code somewhere else (separated by a network connection, or a file, or persistence into a database) that is predicated on undoing those same set of hacks.

I wrote an app that does a different but perhaps even more appalling crime.

The app was for displaying time-series data. The data displayed was only generated during business hours. We usually wanted to view a span of a couple of weeks. Displaying it naively, with real time along the x-axis would mean that three-quarters of the display was blank, with only 40 of a week's 168 hours in use.

The obvious thing to do is to elide the blank bits, and just show the spans of time with data (with a little gap in between). But the charting library i was using didn't have the concept of a discontinuous or nonlinear x-axis.

So i wrote a class called TimeCompressor that would collect a set of time-series data, indexed by epoch timestamp, and rewrite the timestamps so that empty spans of time would be compressed. The earliest timestamp in the dataset stays the same, but later ones may be slid earlier in time to compress empty spans. The resulting indices are numbers which look mostly like epoch timestamps, and in some cases actually are epoch timestamps, but really aren't epoch timestamps.

This was all done in JavaScript, so there wasn't a convenient way to wrap the not-really-timestamp indices in a type to mark them as such. So, in this application, when there's a field called somethingTimestamp and it has a large integer that looks like a timestamp in it, sometimes it's a timestamp, and sometimes it isn't!

I am hoping this application will be retired before i ever need to work on it again.

It's not just timezones names that are bullshit (they are!), the whole calendar is dumb.

Ideally the world should switch to an "earth calendar" where the year begins on the shortest day (currently Dec 21st for 90% of the population) and there are four yearly planet-wide holidays:

1. northern solstice

2. southern solstice

3. northward equinox

4. southward equinox

While we are at it, we could also do something more clever than months, weeks and the time system. 24/60/60 is a pain.

Part marketing ploy, part genuine attempt to improve time systems, especially in a global context, Swatch actually once tried to do so: https://en.m.wikipedia.org/wiki/Swatch_Internet_Time

Unfortunately, .beat time didn’t catch on.

For most people, going to work on Monday and coming home on Tuesday isn't going to catch on (yes some of us work nights, it's rare)

I have often wondered why 10 days after the shortest day was chosen to start the year (Jan 1). Does anyone know why they chose that?

When I use the "full" timezone name like "America/New_York", how does libc resolve the ambiguity during the extra hour of the transition from daylight saving time to standard time?

Tzdb has the date and time that location starts/reverts DST. It is updated regularly to keep up with regions changing the time zones. It happens frequently than many of us like.

I'm not sure I follow (and this week, timezones and time handling are really important for my job, so I really want to understand)!

If a user provides a time of 11/7/2021 1:50 AM America/New_York, how does the library determine if it's a -5 or -4 offset given that's when daylight savings time ends? I believe that's the ambiguity GP is referring to.

I'm trying to align time across a few systems I work with. One provides a GMT time with an offset (clean and useful), another system reports timezones and local time, and yet another system has no idea when it moves between time zones, but reports time based on a single timezone consistently.

Not dealing with multiple timezones in the past, it reminds me of Tom Scott's video on handling time and timezones, summarized at the end as roughly "Go find someone who built a library for handling times, thank them profusely, use their open source code, give them credit, and never worry about it again."

https://youtu.be/-5wpm-gesOY

This also reminds me of the post Jon Skeet wrote about using UTC: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...

Also discussed on HN back in the days: https://news.ycombinator.com/item?id=19500640

> If a user provides a time of 11/7/2021 1:50 AM America/New_York, how does the library determine if it's a -5 or -4 offset given that's when daylight savings time ends?

Edit: I originally misunderstood your question. Since (in the future) 2021-11-07 02:00 is when we change to standard time, how does a library know whether to apply a -5 or -4 offset to 01:50?

The library will need to make assumptions about the inputs and it would probably stick with the original offset (one should check the source). For a human-facing interface, it'd be a good idea to raise the issue.

man mktime on my machine reveals:

> The mktime() function converts a broken-down time structure, expressed as local time, to calendar time representation. The function ignores the values supplied by the caller in the tm_wday and tm_yday fields. The value specified in the tm_isdst field informs mktime() whether or not daylight saving time (DST) is in effect for the time supplied in the tm structure: a positive value means DST is in effect; zero means that DST is not in effect; and a negative value means that mktime() should (use timezone information and system databases to) attempt to determine whether DST is in effect at the specified time.

So, not specified.

POSIX is no clearer about which choice it will make [1]:

> The mktime() function shall convert the broken-down time, expressed as local time, in the structure pointed to by timeptr, into a time since the Epoch value with the same encoding as that of the values returned by time(). The original values of the tm_wday and tm_yday components of the structure shall be ignored, and the original values of the other components shall not be restricted to the ranges described in <time.h>.

> A positive or 0 value for tm_isdst shall cause mktime() to presume initially that Daylight Savings Time, respectively, is or is not in effect for the specified time. A negative value for tm_isdst shall cause mktime() to attempt to determine whether Daylight Savings Time is in effect for the specified time.

> Local timezone information shall be set as though mktime() called tzset().

> The relationship between the tm structure (defined in the <time.h> header) and the time in seconds since the Epoch is that the result shall be as specified in the expression given in the definition of seconds since the Epoch (see XBD Seconds Since the Epoch) corrected for timezone and any seasonal time adjustments, where the names other than tm_yday in the structure and in the expression correspond, and the tm_yday value used in the expression is the day of the year from 0 to 365 inclusive, calculated from the other tm structure members specified in <time.h> (excluding tm_wday).

> Upon successful completion, the values of the tm_wday and tm_yday components of the structure shall be set appropriately, and the other components shall be set to represent the specified time since the Epoch, but with their values forced to the ranges indicated in the <time.h> entry; the final value of tm_mday shall not be set until tm_mon and tm_year are determined.

... but i think the final paragraph implies that the tm_isdst field in the input time should at least be set to indicate which choice was made!

Java is explicit [2]:

> In most cases, there is only one valid offset for a local date-time. In the case of an overlap, where clocks are set back, there are two valid offsets. This method uses the earlier offset typically corresponding to "summer".

[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/m...

[2] https://docs.oracle.com/en/java/javase/11/docs/api/java.base...

Falsehoods Programmers believe about Time https://news.ycombinator.com/item?id=4128208

Really disappointed that the author did not want to delve into TZ dark magic:

  $ date && TZ=LOLS-3:03:03LOLD,J101,J202 date
  Wed Feb 10 17:44:44 EST 2021
  Thu Feb 11 01:47:47 LOLS 2021

(My timezone is LOL Standard Time (LOLS), UTC+03:03:03, with support for changing to LOL Daylight Time (LOLD) during daylight savings, entering LOLD on the 101st Julian day of the calendar, and leaving on the 202nd Julian day of the calendar, excluding February 29th even in leap years.)

I find this magic quite unpleasant. It causes a massive amount of confusion (eg if you write TZ=UTC+8, you actually get UTC-8, except it’s called UTC. You’d actually need to type eg TZ=XYZ-8 because you subtract 8 hours to get UTC. The theory at the time was that it made it easier to enter US timezones like UTC-5.) Furthermore, some applications won’t parse a timezone that isn’t in the local tzdb so you’d actually need to enter eg TZ=Etc/GMT-8 for UTC+8. And heaven forfend an application might parse TZ=UTC+8 in the “normal” way instead of the posix way. What a recipe for disaster. Encoding daylight savings in the env var just makes the whole mess worse.

Is there a way to know which timezone (e.g. America/Phoenix) I'm in right now?

I did actually missed a meeting due to that. I was in small city in Montana, checked list of these timezones, but didn't know which one to choose. So I saw Phoenix has the same time as me, and set it at my device.

However, turned out that Montana actually uses America/Denver (which is Colorado) as their timezone. Is there a way to know that?

the general rule of thumb for American Timezones is that Arizona is its own special thing and as long as you stay out of that state then you're in America/{los_angeles|denver|chicago|new_york} for pacific, mountain, central, and eastern respectively.

Just stay away from Arizona and American time zones are easy and what you did would work.

Arizona is special because it's in mountain time, it doesn't observer daylight saving time so half the year it has the same time as pacific time except for the Navajo Nation which does observe daylight saving time but the Hopi Nation which is entirely inside the Navajo Nation doesn't follow daylight saving.

edit: picture of the Arizona timezone situation https://en.wikipedia.org/wiki/Time_in_Arizona#/media/File:Ar...

Thank you. What about the rest of the Earth?

Time calculation is deceptively hard.

Here's a fun one: are timezones a mathematical construct or a physical construct? By which I mean: is the core of the problem to get the math right or to account for the geography of the planet?

It's a trick question. Timezones are a political construct. If your software is using timezones, it needs to somehow(1) account for changes to law, internationally. Individual countries can choose, for example, to use or stop using daylight savings time. Some have even chosen to shift the longitudinal timezone they consider themselves to be in.

(1) practically speaking, relying on tzdata (https://en.wikipedia.org/wiki/Tz_database) is a great solution to this problem for most use cases... But you need to keep your copy of it updated, because laws change.

Another mistake I’ve seen is using one timezone code used interchangeably with others in the “same” timezone. This is bad because different locales have different DST rules, and because they have different governing authorities which can and do change the rules.

And another still: assuming that all of a state uses the same TZ. Quite a few do not! Arizona for instance has several tribal timezones which honor DST while the state does not. Nevada has a little sliver of mountain time. Michigan has four counties in central time. And so on.

This stuff is hard to get right. And it’s important. “Just use UTC” is often the naive solution but it’s not good enough for a variety of use cases.

Can I just say how grateful I am for good date/time/timezone libraries? Ok, this here library may not be a very good example - but imagine having to write and maintain all that stuff by yourself...

I cringe every time someone send me an email that says "I can meet at 10 PST" no matter what time of the year it is. But what can you do.

As far as the unix utilities go, the behavior is non-intuitive for sure, but can probably never be changed without breaking massive amounts of existing systems. The behavior is also reasonable considering the system constraints at the time it was written. Consulting an ever changing tz database every time the command runs was not an option, and maybe isn't even today.

> I cringe every time someone send me an email that says "I can meet at 10 PST" no matter what time of the year it is.

Why? An average person (read: non-developer) rarely needs to think about their timezone, save for when it changes. As a human, it seems relatively straightforward to intuitively determine whether that person is in DST or not.

If you were a UNIX machine (or a developer providing input to one such machine, I guess), it might be more appropriate to ask for a response in the Americas/Chicago format or something like UTC-0600, but it seems rather coarse to require that everyone adhere to your personal timezone standards when interacting with you.

Personally, I frequently schedule meetings with clients all over the US where their timezone isn't necessarily clear to me, so I usually just say something along the lines of "1045am CT," omitting the S/D in its entirety.

I cringe because I've dealt with so many timezone bugs, because it is notoriously hard to get right. So it is just sort of a PTSD reaction. Of course I know what they mean, I just cringe to myself.

> As a human, it seems relatively straightforward to intuitively determine whether that person is in DST or not.

But you don't know if someone used a calculator and invoked actual PST during the summer.

> I usually just say something along the lines of "1045am CT," omitting the S/D in its entirety.

Good.

It may have to do with the appearance of arrogance in incorrectly using a term they don't understand instead of a simpler term they do.

I wish, although I'm totally aware it'll never happen, that there were no time zones, just UTC and that's it.

One clock for the world. If that meant you started work at 0900 UTC and finished at 1700 UTC then fine, but if you lived in a different part of the world your work day might be 0100-0900.

It'd definitely take a bit of getting used to, but as the world becomes more intertwined, timezones are a pain and constant source of confusion.

Rather than discrete time zones my ideal would be a continuous system which keeps sunrise at the same local time every day, backed by a universal coordinate system like UTC. "Dumb" clocks are set to UTC, "smart" clocks show local time and adjust daily. Sunrise at 8am, just go to bed at the end of the day (midnight) and you'll get a full rest. Call it Adjusted Local Time or something.

everything is discrete if you look fine enough. locally (household-fine) what you say would be nice, however the moment you start travelling informational nightmares would ensue due to human nature, nobody (in the grand scheme) would use the UTC time since local is more useful/frequent so all travellers need translators which can seamlessly translate local time to be as useful as current narional timezones are. such a translator would either be manually preprogrammed(cumbersome) or GPS, computer-powered which brings its own troubles. I think countrywide(as in european country or american state) is a pretty good scale tradedoff between ease of use and accuracy which is here to stay until GPS and computation are ubiquitous(as in every grandma has access to a smart device with GPS she can leave on all day and can be read as easily as a wall clock while having dough all over her hands) sorriez for wall of text :)

The other side of this is people assuming sydney time is brisbane or adelaide time, because they have limited experiental knowledge of a continent. we're well trained with mountain/central/eastern and Hawaii but we sometimes forget that LA is not next door to Chicago, I mean how far can it be?

Well.. Brisbane is not Sydney time. half the year we're 1 hour offset. AEST is not AEDT.

If you think that's bad, there are three distinct time zones which each go by CST.

And even Central Standard Time is ambiguous

https://www.zainrizvi.io/blog/falsehoods-programmers-believe...

I always suspected the Whattimeisitrightnow.com joke on Bojack was inspired by a Sys Admin and hollywood writer getting drunk together.

Nice blog post.

What an important article to read. I've dealt over a decade with timezones, and this short article has shown me something new (EDT is not unique, gets silently set to UTC).

I am in the habit of using "Country/City" on everything that is not UTC, so I never encountered this issue. But it's so good to know.

Nitpick: "Continent/City".

"America" isn't a continent.

America can be a continent. Definitions vary so sometimes it's split into "North America"/"South America", or pluralized "Americas".

TZ database includes "America/Santiago" and "America/Sao_Paulo" so clearly it means the continent and not just the US.

"The seven-continent model is usually taught in most English-speaking countries including the United States, United Kingdom[38] and Australia,[39] and also in China, India, Pakistan, the Philippines, and parts of Western Europe."

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

Definitions do indeed vary, but that's how I learned it, and it would even seem to be the model most often taught.

Which way were you taught?

I can't call someone in India without looking up their timezone and figuring out if they are at work or still sound asleep. Time zones made sense when the only people we could talk to lived close by.

Why not just use one universal time? At least we would know what time to agree on when planing a call. If I already have to look up the time zone in India before I call, it wouldn't be any harder to look up when people in India go to work or have lunch.

While we are at it I think we should move to a decimal time system. 100 seconds in minute, 100 minutes in hour, and 10 hours in a day. Naturally the second would be a bit shorter; the new seconds would be .864 current seconds. Then meetings could be scheduled in tenths of an hour, 0.2 hrs or 0.5 hrs etc.

We'd have to give this new world wide system a name, so that old time wouldn't be confused with new ones. I suggest saying something like 5.00-T8T (which stands for Todd8 Time) perfect!

see also https://en.wikipedia.org/wiki/Decimal_time in case this is not "/s"

Oh, thanks. That's interesting, there's a long history of decimal time.

Afer fixing the time we can fix the calendar. See the Hanke–Henry Permanent Calendar at https://en.wikipedia.org/wiki/Hanke–Henry_Permanent_Calendar

I give you... http://www.swatchclock.com/

Tangentially, is there a standardized format for local time? ISO8601 has the same issue.

What do you mean? ISO8601 specifies a number of formats. It also specifies how to include the timezone/offset, and that not mentioning a timezone means local time.

So how do I properly serialize a datetime in Europe/Prague time zone? As the article explains the use case where "CET" nor "CEST" nor fixed timezone offset is sufficient. And my actual local time zone is Europe/Bratislava, which may eventually differ from Prague.

I think this is out of scope for ISO 8601, especially since the "Europe/Bratislava" label is a specific reference to the tzdata tables. Another system may use another way of specifying the location for the time zone, e.g. GPS coordinates. (Though in practice I don't think anyone does that; literally everyone uses tzdata.)

The "correct" way is presumably to work with an 8601 timestamp without time zone and carry the time zone spec along in an additional field.

I see. I have thought about using phone country/area codes. But they are now less relevant. Also, I remembered how I was on Canary islands - when left phone clock to auto synchronize, I got incorrect Madrid time.

Tom Scott did a fun video of the general nightmare that timezones bring to the dev table: https://youtu.be/-5wpm-gesOY

tzset(3) explains this. GNU is actually sort of bailing the author out in the unfortunate cases like America/New_York where it ignores you forgot to provide the prepending colon.

In terms of EDT, LOL, etc: again, well explained in the tzset manpage. EST works only because it appears the timezone database has EST and again, GNU is being helpful and assuming you meant to add the prepended colon.

> Let's take take a look, using the disastrously bad unix libc timezone tools

It seems to me that the author did not initially read the documentation they linked to (https://www.gnu.org/software/libc/manual/html_node/TZ-Variab...) and is now complaining in an annoying and entitled manner.

It's absolutely right to criticize insane behavior even if said behavior is documented. LOL "helpfully" being substituted to the output is absolutely insane.

No it isn't. If you tell your computer that the timezone your machine is set to is called "LOL", then of course that's what it should report. What else would it do?

It truncated the name because of the underscores, but you can do `TZ=somerandomthing date` to see it just reports what you say it is.

> If you tell your computer that the timezone your machine is set to is called "LOL", then of course that's what it should report. What else would it do?

If `TZ=EST date` adjusts the offset to EST, then a reasonable person would expect `TZ=EDT date` to either adjust the offset to EDT, or fail noisily if it's not aware of that offset code.

At a skim through the documentation I don't see anything warning about it's current behaviour.

> or fail noisily if it's not aware of that offset code.

But it is aware of it! You just told it, using the TZ variable, what EDT is. It's a timezone called EDT, with no offset from UTC!

If you wanted an offset, you should have written `TZ=EDT+4 date`

If I'm understanding the examples, it looks like (in general) commands such as `TZ=EST date` work as expected (i.e. you can set offset just using the offset code).

> But it is aware of it! You just told it

The user didn't intend to. Defining a new offset code should be explicit, not a silent fall-back when it's unable to find EDT.

> The user didn't intend to.

Well, they should have read the docs. They clearly show examples of how to define a timezone right there. It isn't a fallback, it's what TZ is for.

Edit: perhaps `date` should have a `-z --zoneinfo` option, in which you could specify a timezone by file and it would fail if the file did not exist. This would fix the issue and avoid breaking existing scripts.

> Well, they should have read the docs

You can say that about any bad design choice, and in this case I'd argue that the linked docs don't even agree with the behaviour. The syntax given by the docs for creating a new timezone requires explicitly specifying an offset (then optional stuff like daylight savings).

The quirk may be documented elsewhere, but before getting caught out by it the average user has no reason to be searching through multiple sources of documentation for an oddity they don't yet know exists.

> It isn't a fallback, it's what TZ is for.

If I'm understanding, `TZ=EDT` will search for an "EDT" timezone in its database, fail, then instead silently default to creating a new timezone with 0:00 offset. That's pretty much how I'd define a fall-back.

why doesn't this work the same way for 'EST' then? You don't specify offset so it should just display in UTC as well, right?

Because it has additional information in a file in `/usr/share/zoneinfo`.

But you can still define a brand new timezone with the TZ variable. Perhaps you want to argue that you shouldn't be able to, but that's what it's for, as the document linked above clearly states.

Various behaviors when requesting time in a non-existent timezone:

sane: report an error in some hard to ignore form

less sane: ignore the provided timezone, display the time in UTC and properly mark it with "UTC"

insane: ignore the provided timezone, display the time in UTC, but then mark it with the prefix of the provided timezone anyway.

I don't care how well documented the insane behavior is, it's still insane.

It didn't display the time in UTC, it displayed the time in timezone LOL. It happened to be the same as UTC because no offset was specified. It knew it was timezone LOL because that's what the TZ variable was set to.

If you set your machine to something weird, then expect the utility that reports on those settings to report the weird settings you set.

Not defending/attacking the phrase "disastrously bad", but I'm not sure its a fair argument to say "the docs explain it", if the behavior isn't what a "reasonable" person would expect. Writing software that deletes your files (when you expect, say, the weather report) isn't excused if they write in the docs "oh this weather software randomly deletes files for no reason".

In this specific case though, even those docs do not explain what happens if the value is "invalid"!

Let's pick apart that documentation and the actual behavior, shall we?

By the documentation "EST", "EDT" and "America/Los_Angeles" are not valid TZ environment variable values, as none of them matches any of the formats. offset doesn't seem to be optional, and within offset hours are not optional.

Ok, maybe it is too pedantic, a permissive implementation can interpret no offset as 0, right? But that's not what happens here. The implementation looks up the timezone by the provided name somewhere, and only when it doesn't find it it falls back to 0 as an offset.

This lookup behavior doesn't seem to be documented on that page. It's not described in the GNU date man page either even though it uses TZ='America/Los_Angeles' as an example.

tzset manpage for glibc explains this:

         If  the file specification filespec is omitted, or its value cannot be interpreted, then Coordi‐
       nated Universal Time (UTC) is used.  If filespec is given, it specifies another tzfile(5)-format
       file  to  read  the  timezone information from.  If filespec does not begin with a '/', the file
       specification is relative to the system timezone directory.  If the colon is omitted each of the
       above TZ formats will be tried.

Ok, so the key quote here: "If the colon is omitted each of the above TZ formats will be tried."

So even if someone finds this sentence somehow this is still underspecified. The full logic seems to be for a TZ that doesn't start with ':' :

1. First format tried, if it fails...

2. ...interpret TZ as filespec, if it fails...

3. ...interpret TZ as std with offset 0.

Note that there is fallback parsing of TZ that is not described at all (essentially 3rd and 4th formats), and two fallbacks, not one.

I believe the best move (literally) I ever made was to migrate from GMT-3 to (mostly) UTC.

Odd, I have been using CST6CDT on my OpenBSD servers. Is this not a normal construction?

you'd have to constantly update your TZ to reflect changing transition periods, which you don't even specify. using a tzdata file, you get this for free plus proper transitions for older dates.

Uhm... CST6CDT has zone info just like America/Chicago or America/New_York. What am I missing?

FACEPALM

It's not "EST", it's EST5EDT because the string "EST" shows up in other time zone designations. Learn time zones, then come back.

not this again. every one hates timezones. they are poorly designed and incorrect to begin with. move on.

Obligatory post to Computerphile episode about Timezones - a must watch for developers just starting out with Timezones

https://www.youtube.com/watch?v=-5wpm-gesOY

no standards = bullshit

Reply on news.ycombinator.com