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

231–240 of 334 posts

Re: Timezone Bullshit

#231

Post by mikestew »

jolmg wrote: post #223
xyzelement wrote: post #216

Earlier quoted context omitted.

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

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.

Re: Timezone Bullshit

#232

Post by 1-more »

siculars wrote: post #81
jmgao wrote: post #31

Earlier quoted context omitted.

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

They already do. See Arizona.

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

Re: Timezone Bullshit

#233

Post by prussian »

protomyth wrote: post #153

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.

Re: Timezone Bullshit

#234

Post by filoleg »

jolmg wrote: post #223
xyzelement wrote: post #216

Earlier quoted context omitted.

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

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.

Re: Timezone Bullshit

#235

Post by prussian »

steerablesafe wrote: post #196
phoronixrly wrote: post #3

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

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
       above TZ formats will be tried.

Re: Timezone Bullshit

#236

Post by mikelward »

phlo wrote: post #36
jwalton wrote: post #27

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…

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

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

Re: Timezone Bullshit

#237

Post by ben509 »

jolmg wrote: post #223
xyzelement wrote: post #216

Earlier quoted context omitted.

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

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

Re: Timezone Bullshit

#238

Post by pjungwir »

bob1029 wrote: post #5

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

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

Re: Timezone Bullshit

#239

Post by cwmma »

deepsun wrote: post #230

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

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

Re: Timezone Bullshit

#240

Post by marcosdumay »

kenniskrag wrote: post #44
Hamuko wrote: post #35

Earlier quoted context omitted.

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?

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

Post reply on HN