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

261–270 of 334 posts

Re: Timezone Bullshit

#261

Post by netsharc »

seszett wrote: post #15
soco wrote: post #11

Earlier quoted context omitted.

The GUI elements should have nothing to do with storing and interchanging timestamps. What you display can query the browser timezone to make it look nice, then send it down converted, over.

You cannot convert a time string in the future to a timestamp. You must keep it as a string with timezone information until the time actually comes.

IMO depending on the use case, just the TZ info won't save you. Say I arrange a meeting for 4pm local time (where summer daylight savings time will be active) for July 2022.. and then the city I want to meet in gets invaded by a foreign army and changes its timezone. And cancels summer time. What time is my meeting now?

I guess it needs to be a 4-dimensional coordinate, where 1 axis can slide around...

Re: Timezone Bullshit

#262

Post by bob1029 »

netsharc wrote: post #6
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…

Hmm, your applications don't have user input asking for a time?

We do have one case where we do have to capture the hour of day for an IT activity. In this situation, we present the UI in the timezone configured by the customer's server and additionally display this timezone information in the UI as reference/confirmation for the user. Once the user submits their input in terms of server-local time, we immediately convert it to UTC for storage in our system. Note that because we present the actual TZ info, this even supports servers that are already configured for UTC. We have no edge cases aside from ensuring our users pay attention to the TZ info.

I still don't understand the arguments about a future date requiring a timezone. UTC can 100% accurately represent a future date or event without any ambiguity. If a user, meeting or other aggregate has a culture/timezone preference, this is a completely separate business fact from the time.

Re: Timezone Bullshit

#263

Post by jpitz »

treesprite82 wrote: post #250
jpitz wrote: post #170

Earlier quoted context omitted.

"America" isn't a continent.

America can be a continent. Definitions vary so sometimes it's split into "North America"/"South America", or pluralized "Americas". TZ database includes "America/Santiago" and "America/Sao_Paulo" so clearly it means the continent and not just the US.

"The seven-continent model is usually taught in most English-speaking countries including the United States, United Kingdom[38] and Australia,[39] and also in China, India, Pakistan, the Philippines, and parts of Western Europe."

https://en.wikipedia.org/wiki/Continent

Definitions do indeed vary, but that's how I learned it, and it would even seem to be the model most often taught.

Which way were you taught?

Re: Timezone Bullshit

#264

Post by davchana »

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.

I am from India, northern part, where there is a lotbof variation between sunlight hours throughout the year. Some days the sun is out at 6 or before in summer, & in winter its some time not out even till 9 or such.

India does not use timezones. Every business, school, office who has business hours, use something like Winter Timings Summer Timings. Schools & such use 14 Oct to 14 Apr as Winter, & other 6 months as summer. My school used to open at 6 in summers, & 7:30 or 8 in winters.

Here in US they keep the opening timings same throughout the year, but go through this DST shenanigans.

Re: Timezone Bullshit

#265

Post by inglor_cz »

SamBam wrote: post #125
remram wrote: post #119

Earlier quoted context omitted.

Your argument sounds very similar to the "let's abolish timezones" argument so let me post this again: https://qntm.org/abolish Changing your schedule works for you and your boss, but does not let people in other parts of the world know when they can reach you. Officially shifting something is necessary, and then you might as well have timezones.

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 should have their breakfast at the same time. It just did not serve any obvious purpose.

There are only two exceptions I can think of.

a) people doing astrological horoscopes for someone who was born in a different place (a big thing among some nobility and royalty) would probably be bothered a bit by the time difference,

b) armies trying to converge on the same target at the same moment.

Re: Timezone Bullshit

#266

Post by jacobsenscott »

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 changing tz database every time the command runs was not an option, and maybe isn't even today.

Re: Timezone Bullshit

#267

Post by javbit »

sdm wrote: post #9

> There are actually two timezones that are canonically named "CST", and they're 14 hours apart! Yup. If you say CST do you mean China Standard Time or Central Standard Time? The answer will depend on where you live in the world. There are others that share the same abbreviation as well. But CST is the one that constantly causes trouble in daily life. Just say no.

I got bit by this when scheduling an interview. It's interesting because it's not that much harder to say America/Chicago (or just Chicago) but it's just by default I tend to say CST, CDT, etc. Started using UTC offsets but not many people know those off the top of their heads.

Re: Timezone Bullshit

#268

Post by Spivak »

jonathanberger wrote: post #200
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.

Unfortunately the statement is not true. One good reason to use short timezone codes like EST, CST, PST is that most people prefer them. One of the first surprising things you learn after launching a timezone conversion website https://news.ycombinator.com/item?id=1133613 is that one of the top feature requests is to display short timezone codes.

And people prefer them because I have known since I was like 4 that I'm on Eastern time but have exactly zero idea what my UTC offset is off the top of my head. And also because I observe daylight savings EST changes automatically for me while I have to remember whether I'm in DST to know my UTC offset.

Re: Timezone Bullshit

#269

Post by bslorence »

ubermonkey wrote: post #110
tallanvor wrote: post #26

Earlier quoted context omitted.

What if you're scheduling a meeting for multiple people, and normally you're in Seattle, but for some of these meetings you'll be in New York? You don't want the meeting to be at 8:00 your time because chances are the people in Seattle aren't going to join your call at 5:00 their time.

As someone who routinely sets meetings for people in multiple timezones, let me say this isn't confusing. All the calendaring tools I use or am aware of, at this point, keep up with time zone correctly (or have so far). I set the meeting for, say, 10 CST, and it's clear to my colleagues in Seattle that it will be 8 for them, just as it's clear for my coworkers in DC that it'll be 11.

Twice a year we have to deal with calendar screw-ups because a third of our employees are in a locale that doesn't observe DST and the rest are in locales that do observe it. If an employee from that first group sets up a recurring meeting, the meeting time changes for everyone else in March and November.

Re: Timezone Bullshit

#270

Post by toyg »

ceilingcorner wrote: post #73
Lvl999Noob wrote: post #66

Earlier quoted context omitted.

Perhaps it was easier in the times before the internet. Now a consistent timeline should be far more convenient than not having to change your habits by a little bit. Edit: If changing schedule is normalized, then it would be just as convenient as changing the clock. In countries without DST, if someone started using DST instead of changing their own schedule, it would be just as difficult.

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 unpopular. The population at large simply does not benefit, it was introduced for the good of industry and we're largely leaving behind that world. Good riddance.

Post reply on HN