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

Timezone Bullshit

blog.wesleyac.com

Post reply on HN
Print view View original

311–320 of 334 posts

Re: Timezone Bullshit

#311

Post by prerok »

throw0101a wrote: post #52
Lvl999Noob wrote: post #43

Earlier quoted context omitted.

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/edin…

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

Re: Timezone Bullshit

#312

Post by kanzenryu2 »

todd8 wrote: post #289

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 i…

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

Re: Timezone Bullshit

#313

Post by GoblinSlayer »

remram wrote: post #297
GoblinSlayer wrote: post #213

Earlier quoted context omitted.

It's just the best way of contact, if people know anything else, they can use it, but even in one building it's impossible to know who is on vacation, who is fired, who is on lunch, who is on a smoking break, who is off on an errand, who left a little earlier, who is busy at a meeting, who is just busy.

Good for you. Obviously the rest of the world uses phones and video calls, which is why this thread exists. You should give them a try sometime!

As I said even in the same building it's impossible to video call, because people aren't killing time all day long.

Re: Timezone Bullshit

#314

Post by kstenerud »

lolc wrote: post #277
kstenerud wrote: post #12

Earlier quoted context omitted.

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 con…

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.

Re: Timezone Bullshit

#315

Post by rini17 »

eqvinox wrote: post #111
rini17 wrote: post #104

Earlier quoted context omitted.

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 t…

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.

Re: Timezone Bullshit

#316

Post by jobigoud »

davidgh wrote: post #107
mabbo wrote: post #47

Earlier quoted context omitted.

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…

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 th…

> 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.

Re: Timezone Bullshit

#317

Post by [deleted] »

prussian wrote: post #235
steerablesafe wrote: post #196

Earlier quoted context omitted.

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 happen…

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 a…

[deleted]

Re: Timezone Bullshit

#318

Post by steerablesafe »

prussian wrote: post #235
steerablesafe wrote: post #196

Earlier quoted context omitted.

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 happen…

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 a…

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.

Re: Timezone Bullshit

#319

Post by cfstras »

prussian wrote: post #229
cfstras wrote: post #99

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.

Re: Timezone Bullshit

#320

Post by Piskvorrr »

inglor_cz wrote: post #265
SamBam wrote: post #125

Earlier quoted context omitted.

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…

> 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…

...didn't bother anyone until railroads entered the equation: astrology did take the difference into account, armies didn't move quickly enough to notice it: just keep adjusting to local time every day or so (even on horseback, any tactic is far more dependent on physical limits, so you're coordinating on the order of minutes, not milliseconds).

For railroads, even at 40 kph, an east-west train would be subject to time shift (not in the Lorentz sense, it would just keep switching "timezones" too quickly). Given that the primary security element was "this train is supposed to pass this set of switches between this and that time and wait there, else it risks colliding with that other train running opposite," both accurate timekeeping and geographically wider timezones were needed (as in "the railroad will use its own time, Prague's lunchtimes notwithstanding").

Post reply on HN