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

171–180 of 334 posts

Re: Timezone Bullshit

#171

Post by [deleted] »

Lvl999Noob wrote: post #43
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…

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.

[deleted]

Re: Timezone Bullshit

#172

Post by phaemon »

treesprite82 wrote: post #158
phaemon wrote: post #115

Earlier quoted context omitted.

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

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

Re: Timezone Bullshit

#173

Post by arminiusreturns »

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

Re: Timezone Bullshit

#174

Post by icoder »

ghaff wrote: post #140
u678u wrote: post #132

Earlier quoted context omitted.

If they find time changes disruptive, changing schedules instead of time is going to be equally disruptive.

Sure. My assumption is that absent formal time changes, schedules won't change and people will just live with what, for many, is sub-optimal schedules with respect to sunlight.

So then you're back to square one right? Where (apparently) the preference was given to DST (with its downsides), above sub-optimal schedules.

(Edit: Combining both your replies I think that may actually be your point)

Re: Timezone Bullshit

#175

Post by CydeWeys »

ghaff wrote: post #157
CydeWeys wrote: post #149

Earlier quoted context omitted.

More of a headache, even. Sadly, DST is the only good way to have everyone synchronize a schedule change like this.

Those who argue for eliminating DST but somehow still preserve some form of winter/summer hours are basically arguing for eliminating DST and then recreating it poorly. You either do DST or you mostly just pick a timezone and stick with it year round.

I like the latter approach: year-round DST. Not even sunlight in the evening is frequently a problem for me, but not enough sunlight in the morning isn't.

Re: Timezone Bullshit

#176

Post by toomanybeersies »

AnIdiotOnTheNet wrote: post #57
throw0101a wrote: post #52

Earlier quoted context omitted.

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…

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

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

Re: Timezone Bullshit

#177

Post by TheRealSteel »

CydeWeys wrote: post #147
Lvl999Noob wrote: post #53

Earlier quoted context omitted.

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.

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

Re: Timezone Bullshit

#178

Post by ghaff »

icoder wrote: post #174
ghaff wrote: post #140

Earlier quoted context omitted.

Sure. My assumption is that absent formal time changes, schedules won't change and people will just live with what, for many, is sub-optimal schedules with respect to sunlight.

So then you're back to square one right? Where (apparently) the preference was given to DST (with its downsides), above sub-optimal schedules. (Edit: Combining both your replies I think that may actually be your point)

My preference is definitely to slant towards evening sunlight, so DST year round. (I actually live somewhere that should really be in the next timezone east anyway.) Though I'm at least somewhat sympathetic to people who don't want kids to be waiting for school buses or otherwise heading to school in pitch darkness in the winter.

Re: Timezone Bullshit

#179

Post by fishywang »

ceilingcorner wrote: post #60
AnIdiotOnTheNet wrote: post #57

Earlier quoted context omitted.

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.

Re: Timezone Bullshit

#180

Post by shadowgovt »

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.

Post reply on HN