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

251–260 of 334 posts

Re: Timezone Bullshit

#251

Post by jolmg »

ben509 wrote: post #237
jolmg wrote: post #223

Earlier quoted context omitted.

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

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

Re: Timezone Bullshit

#252

Post by HideousKojima »

NateEag wrote: post #63
de_Selby wrote: post #20

Earlier quoted context omitted.

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

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

Re: Timezone Bullshit

#253

Post by wahern »

freeopinion wrote: post #245
jolmg wrote: post #223

Earlier quoted context omitted.

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

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

Re: Timezone Bullshit

#255

Post by HideousKojima »

arminiusreturns wrote: post #173
juddgaddie wrote: post #29

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

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

Re: Timezone Bullshit

#256

Post by fireattack »

xyzelement wrote: post #216
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.

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.

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?

Re: Timezone Bullshit

#257

Post by notJim »

fireattack wrote: post #256
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.

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.

Re: Timezone Bullshit

#258

Post by ttymck »

rbanffy wrote: post #21
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…

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

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

Re: Timezone Bullshit

#259

Post by protomyth »

prussian wrote: post #233
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.

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

Re: Timezone Bullshit

#260

Post by bjourne »

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

Post reply on HN