Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Falsehoods programmers believe about time and time zones

creativedeletion.com

Post reply on HN
Print view View original

71–80 of 83 posts

Re: Falsehoods programmers believe about time and time zones

#71

Post by return0 »

DanAndersen wrote: post #47
return0 wrote: post #27

Would it be too much to have a global movement for uniform time standards? No half-hour timezones, no daylight savings, no leap seconds, just easily predictable time. Calendars are supposed to be convenient, and right now our ancient conventions make it difficult to understand each other (not just computers; think of travelers having to adjust to timezones, "do I need DST or not?"). At least, lets think of the electr…

You may be interested in the following articles: "So you want to abolish time zones" https://qntm.org/abolish >We already do have a global standard time zone, and everybody who cares already uses it: UTC. There are also more accurate time standards in use for more specialist purposes. "You advocate a ________ approach to calendar reform" https://qntm.org/calendar These links helped convince me that while time zones a…

I think timezones are useful. But the rest is not. We could just agree on a (non-solar) calendar that is predictable for the next, say 1000 years.

Re: Falsehoods programmers believe about time and time zones

#72

Post by leni536 »

laut wrote: post #49
WalterBright wrote: post #9

Dealing with timezones and daylight savings time has consumed hundreds of hours of my development time. This seriously should be a standard service of the operating system, not the programming language library. Just look at all the code to deal with it in D (written by Jonathan Davis): https://github.com/dlang/phobos/blob/master/std/datetime.d

Operating systems kind of suck at it. Which is why for Elixir I made Tzdata ( https://github.com/lau/tzdata ) not rely on any timezone information from the operating systems. A feature I would like from operating systems is to tell me the true time during leap seconds. E.g. 23:59:59, 23:59:60, 00:00:00 Instead of repeating 23:59:59 or just pretending the leap second never happens.

I just checked if you can get around it by using unix time, but holy shit, it is poorly designed. Unix' seconds since epoch is not the actual absolute number of seconds since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970, it doesn't count leap seconds. I wonder if you can even get a reliable TAI from linux, so you can abandon all this shit and implement proper time handling yourself.

Edit: Seems like we can specify CLOCK_TAI for clk_id on linux now.

Re: Falsehoods programmers believe about time and time zones

#73

Post by Piskvorrr »

justinator wrote: post #53
themartorana wrote: post #40

Earlier quoted context omitted.

I couldn't agree more - to boot, DST going away solves like half of the edge cases with one quick fix.

Except that removing DST won't, if you ever need to calculate a time/date for any time before its (future, hypothetical) removable. That could actually create more bugs.

Probably won't, historical DST switches (and TZ offsets) are already one of the edge cases a TZ library needs to deal with (I'm looking at you, Argentina!).

Re: Falsehoods programmers believe about time and time zones

#74

Post by Piskvorrr »

pmiller2 wrote: post #36
douche wrote: post #25

Earlier quoted context omitted.

That is one of my all-time favorite youtube videos... This one, and a similar one on unicode[1], are my goto exhibits when I need to illustrate to a non-technical family member how much background complexity is involved in software [1] https://www.youtube.com/watch?v=MijmeoH9LT4

I would think the time zone example would go over better than Unicode, because it's less esoteric. Almost everybody deals with time zones at some point; not everybody deals with Unicode.

Surely they do. They're just not aware of it ;)

(Yes, yes, amounts to the same thing. Except when it breaks.)

Re: Falsehoods programmers believe about time and time zones

#75

Post by Piskvorrr »

Fuzzwah wrote: post #35
return0 wrote: post #27

Would it be too much to have a global movement for uniform time standards? No half-hour timezones, no daylight savings, no leap seconds, just easily predictable time. Calendars are supposed to be convenient, and right now our ancient conventions make it difficult to understand each other (not just computers; think of travelers having to adjust to timezones, "do I need DST or not?"). At least, lets think of the electr…

Swatch Internet Time is going to really take off one day.... https://en.wikipedia.org/wiki/Swatch_Internet_Time

With the resurgence of faxing, perhaps.

Re: Falsehoods programmers believe about time and time zones

#76

Post by Piskvorrr »

return0 wrote: post #71
DanAndersen wrote: post #47

Earlier quoted context omitted.

You may be interested in the following articles: "So you want to abolish time zones" https://qntm.org/abolish >We already do have a global standard time zone, and everybody who cares already uses it: UTC. There are also more accurate time standards in use for more specialist purposes. "You advocate a ________ approach to calendar reform" https://qntm.org/calendar These links helped convince me that while time zones a…

I think timezones are useful. But the rest is not. We could just agree on a (non-solar) calendar that is predictable for the next, say 1000 years.

...now you have 15 competing standards.

https://xkcd.com/927/

Re: Falsehoods programmers believe about time and time zones

#77

Post by Scarblac »

pg_bot wrote: post #31
deathanatos wrote: post #22

Earlier quoted context omitted.

> It bothers me that a minute is not always 60 seconds. For leap seconds why did we choose 23:59:60 instead of 24:00:00? But how does this solve the problem? Sure, 23:59 is now 60 seconds long, but the minute 24:00 is only 1 second long.

It's about consistency. 23:59:60 is introducing a special case to the seconds field which you have to account for. 24:00:00 only adds a second to the day where it naturally should go. I don't redefine what a minute is, a minute is always 60 seconds. You are confusing two separate ideas, displaying a time and finding the difference between two times. Lexically you wouldn't say that minute is 1 second long, you would s…

Surely "24" introduces a special case to the hours field which you have to account for?

Re: Falsehoods programmers believe about time and time zones

#78

Post by x1798DE »

majewsky wrote: post #67
leni536 wrote: post #66

> If I have a timestamp for a future event, I can convert it to UTC, store it as UTC along with the time zone and be sure that I can reliably convert it back to the correct “wall time” in the future This actually looks like a subtle type safety and casting problem. Not all time specifications belong to the same type.

I guess they refer to jurisdictions changing their time zones or DST rules every so often. Note how they're only talking about the future, because that's where policy changes typically apply.

Even if there were retroactive changes for some reason, generally when storing a time in the past, you want to know the actual time it occurred, so a conversion to UTC when storing the time stamp is unambiguous.

For future dates, you are often trying to represent "wall time", not a specific point in time, which is why storing as UTC is the wrong representation - it's something that maps to the information you want, but the mapping can change between storage and retrieval.

Re: Falsehoods programmers believe about time and time zones

#79

Post by mscman »

WalterBright wrote: post #30
ShrpErinaceidae wrote: post #18

Earlier quoted context omitted.

"(Sorry about that, but we can’t show files that are this big right now.)" 1.3MB and it's actually raw code. Amazing.

Daylight Savings Time should die in the fires of hell.

We didn't have DST in most of Indiana until about 10 years ago. When we switched, most of us were wondering why the hell we were even doing it. It's really not necessary, it confuses people, leads to screwed up schedules when the switch happens, and the fact that there are still a few counties that don't observe it screws things up even more.

Re: Falsehoods programmers believe about time and time zones

#80

Post by return0 »

Piskvorrr wrote: post #76
return0 wrote: post #71

Earlier quoted context omitted.

I think timezones are useful. But the rest is not. We could just agree on a (non-solar) calendar that is predictable for the next, say 1000 years.

...now you have 15 competing standards. https://xkcd.com/927/

TBH the other 14 arent much better :)
Post reply on HN