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

271–280 of 334 posts

Re: Timezone Bullshit

#271

Post by kukx »

fishywang wrote: post #179
ceilingcorner wrote: post #60

Earlier quoted context omitted.

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

Yes, it is similar to how creating inflation by the government is just a way to tax poor and the middle class, without actually rising taxes.

Re: Timezone Bullshit

#272

Post by kelnos »

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…

I (living in California) usually use "PST8PDT", which does what I want, all year round (for some irrational reason I refuse to claim that I live in Los_Angeles[0]). I believe there's also "EST5EDT", "CST6CDT", and "MST7MDT" as well.

But agree that this is just a grab bag of confusing garbage.

[0] I suppose if CA does away with DST (or keeps it permanently), I will have to change...

Re: Timezone Bullshit

#273

Post by jackson1442 »

jacobsenscott wrote: post #266

I cringe every time someone send me an email that says "I can meet at 10 PST" no matter what time of the year it is. But what can you do. As far as the unix utilities go, the behavior is non-intuitive for sure, but can probably never be changed without breaking massive amounts of existing systems. The behavior is also reasonable considering the system constraints at the time it was written. Consulting an ever changin…

> I cringe every time someone send me an email that says "I can meet at 10 PST" no matter what time of the year it is.

Why? An average person (read: non-developer) rarely needs to think about their timezone, save for when it changes. As a human, it seems relatively straightforward to intuitively determine whether that person is in DST or not.

If you were a UNIX machine (or a developer providing input to one such machine, I guess), it might be more appropriate to ask for a response in the Americas/Chicago format or something like UTC-0600, but it seems rather coarse to require that everyone adhere to your personal timezone standards when interacting with you.

Personally, I frequently schedule meetings with clients all over the US where their timezone isn't necessarily clear to me, so I usually just say something along the lines of "1045am CT," omitting the S/D in its entirety.

Re: Timezone Bullshit

#274

Post by kelnos »

mikelward wrote: post #236
phlo wrote: post #36

Earlier quoted context omitted.

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

Right, but that's because people are misinformed as to how timezones work. EST means UTC-5; people who refer to EST as current during the summer are incorrect. Most news outlets avoid the problem by just saying "ET" or "Eastern Time", which I wish more people would do.

Re: Timezone Bullshit

#275

Post by kelnos »

ttymck wrote: post #258
rbanffy wrote: post #21

Earlier quoted context omitted.

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

Sort of. If you expect to have to deal with people in other time zones, though, you still need to carry time zone information, so the person who lives in New York will correctly dial in to the meeting at their noon and not their 9am.

(This also raises the point that you need to preserve zone information, not just the UTC offset. Otherwise the meeting will move after a daylight saving time change, which is not usually what people want.)

Re: Timezone Bullshit

#276

Post by joquarky »

sschueller wrote: post #28

I'm still hoping .beat time[1] will catch on but I have been waiting since 1998... I even made a watch-face for my smartwatch showing .beats [1] https://en.wikipedia.org/wiki/Swatch_Internet_Time

Another alternative is to base time on the current longitude of the solar meridian.

Re: Timezone Bullshit

#277

Post by lolc »

kstenerud wrote: post #12
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…

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?

Re: Timezone Bullshit

#278

Post by BrandoElFollito »

toyg wrote: post #270
ceilingcorner wrote: post #73

Earlier quoted context omitted.

I don’t think anyone other than programmers thinks DST is much of an inconvenience. The clock changes twice a year, big deal. That’s infinitely less complicated than asking your boss if you can start earlier, which means the store at the subway station will need to be open an hour earlier (since its business comes from commuters), which means restaurants will need to be open earlier to address the lunch crowd, which…

> I don’t think anyone other than programmers thinks DST is much of an inconvenience. I don't think anyone other than programmers thinks DST is not a huge pain in the ass. Twice a year your bodyclock gets screwed up and you risk getting to work at the wrong time; once a year you even get a shorter night of sleep. In Europe (hardly "programmer's country"), it took very simple polling to discover that DST was hugely un…

To be fair, the polling went largly unnoticed (at least in France). I discovered it by chance in the middle of summer, shortly before it got closed.

Then the results were published and a few people were pissed off for not having been informed.

OTOH, it would have had been a discussion for 20 years otherwise.

I am happy we just have one tole shift left (to move to summer time, yay for me because I am on the western edge of a timezone)

Re: Timezone Bullshit

#279

Post by apaprocki »

Really disappointed that the author did not want to delve into TZ dark magic:

  $ date && TZ=LOLS-3:03:03LOLD,J101,J202 date
  Wed Feb 10 17:44:44 EST 2021
  Thu Feb 11 01:47:47 LOLS 2021
(My timezone is LOL Standard Time (LOLS), UTC+03:03:03, with support for changing to LOL Daylight Time (LOLD) during daylight savings, entering LOLD on the 101st Julian day of the calendar, and leaving on the 202nd Julian day of the calendar, excluding February 29th even in leap years.)

Re: Timezone Bullshit

#280

Post by jws »

somehnguy wrote: post #220
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 aims to shift the usable daylight hours to correspond with human activity. But it fails miserably at it.. Here in NYS all winter long it gets dark at 5PM. Summer, 9PM. It's useless and just causes inevitable confusion every year.

There’s nothing to be done about winter, that is the “regular” time and you live in the north. You only get the sun above the horizon for 9 hours a day in late December.

The summer 9pm is the advantage of daylight savings. You get the sun up for 15 hours a day! Norther summer is great. Without daylight savings time, you’d get dark at 8pm in the summer and have an hour of “wasted” daylight before you got up. The “savings” part is to take the wasted light while you are sleeping and move it to the evening when you can enjoy it.

It does cause confusion though, and having implemented daylight savings code there are a bewildering number of rules around the world, there are even places that have double daylight savings. They shift once, then shift again for a two hour offset.

Post reply on HN