Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Time to Dump Time Zones

nytimes.com

Post reply on HN
Print view View original

191–200 of 555 posts

Re: Time to Dump Time Zones

#191

Post by roel_v »

axlee wrote: post #183
roel_v wrote: post #176

Earlier quoted context omitted.

"Verbally, speaking with USians, 15.00 is always pronounced "3pm"." It's like that everywhere in Europe. Nobody says 'see you at fifteen'. 24 hour clock is merely for writing things down. I mean it would already be an improvement if the US would catch up with that, just saying that a 24 hour clock isn't said out loud as such. (not disagreeing or anything with you I guess, just adding some information).

> It's like that everywhere in Europe. Nobody says 'see you at fifteen'. Not really? In France it's perfectly normal to say "Rendez-vous à quinze heures" or "Le film commence à vingt-deux heures trente"

OK, it might be a social construct. I'd never say 'treize heures' to set a time with my Parisian colleagues, and neither would they (to the best of my recollection). Sometimes people would say it, yes, but it'd sound strangely artificial, like read literally from a schedule - which in many cases it would be.

Re: Time to Dump Time Zones

#192

Post by grzm »

mkj wrote: post #184
powvans wrote: post #102

I've spent the last several years developing applications that have calendaring at the core, where users collaborate across timezones, and where proper timezone handling is expected. Just try to explain to everyday people just how hard the problem is, the technical in and out, the practical miracle that it all works in almost all the cases, that all the error prone complexity can be eliminated by acknowledging that i…

In my experience it's better to store local time (where the event physically happens) with a named timezone. That way when daylight saving laws change with 3 weeks notice you can adjust without shifting events (cough Outlook). UTC can be calculated easily if needed.

I can see how this could work for recording timestamps as they happen, or for events that have already happened. In this case, you still need to keep around the tables of time zone changes if you ever want to compare two timestamps.

How do you handle future timestamps when time zone data changes? Update all future timestamps? Keep a separate timestamp recording the timestamp at which the future timestamp was last updated?

Storing timestamps at UTC solves this at the expense of knowing how to view the timestamp at a specific time zone.

Re: Time to Dump Time Zones

#193

Post by uryga »

upofadown wrote: post #147

If you have UTC and solar time available, you don't need zone time anymore. If you need to coordinate with other people you use UTC. If you want to do things at a particular time of day you use solar time. If you decide to go to work at, say, an hour after sunrise you get all the advantages of DST, anywhere in the world, without any of the disadvantages. The reason DST sucks is because of the way time zones force all…

To be honest I'm surprised at how simple this UTC/Local solution is. I feel like we reinvent absolute/relative in many different areas, and act really surprised each time... That concept is so universal, it's beautiful.

Re: Time to Dump Time Zones

#194

Post by maxerickson »

roel_v wrote: post #178
iamdave wrote: post #153

Earlier quoted context omitted.

I do. Granted, I was in the military-I passively hate it when people call it 'military time' (passively meaning I mentally roll my eyes when someone says it), but I've been using it since middle school when I first even learned it was a thing. Mostly because it made sense right away. There are 24 hours in the day. Why are we recycling numbers in our time system? No really, why?

Because there are only 12 major divisions on a clock. An analog clock, that is. It reads the same at 3am and 3pm. So from that pov it only makes sense to call it the same.

There are also analog clocks with 24 divisions.

https://en.wikipedia.org/wiki/24-hour_analog_dial

I guess 12 hour clocks are an easy trick to make them easier to read and manufacture and so on.

Re: Time to Dump Time Zones

#195

Post by JumpCrisscross »

CalRobert wrote: post #40
semi-extrinsic wrote: post #23

Earlier quoted context omitted.

Regarding UTC: when I've tried (as a European) to coordinate online meetings with Americans (working in tech companies) using times given in UTC, it's gone wrong about 50% of the time. Usually caused by people confusing UTC and British Summer Time (UTC+1).

I am shocked when I meet an American who actually knows when to use PDT as opposed to PST. They also think they're being clever asking if I want to have a meeting at X:00 GMT when they mean BST (or Irish Standard Time, which is confusingly observer in Ireland in the _summer_, which is 1 hour ahead of GMT just like BST is). Of course, when the S can mean either "summer" or "standard" one can forgive some confusion.

I've switched to 3PM ET or, better yet, 3PM New York time.

Re: Time to Dump Time Zones

#196

Post by detaro »

grzm wrote: post #192
mkj wrote: post #184

Earlier quoted context omitted.

In my experience it's better to store local time (where the event physically happens) with a named timezone. That way when daylight saving laws change with 3 weeks notice you can adjust without shifting events (cough Outlook). UTC can be calculated easily if needed.

I can see how this could work for recording timestamps as they happen, or for events that have already happened. In this case, you still need to keep around the tables of time zone changes if you ever want to compare two timestamps. How do you handle future timestamps when time zone data changes? Update all future timestamps? Keep a separate timestamp recording the timestamp at which the future timestamp was last upd…

That's exactly the point, but the other way around.

If the timestamp is defined in local time (e.g. "a meeting is scheduled for 15:00 every second thursday") and you generate a list of the next events as UTC, and then the DST rules change, you have to go in and fix all the UTC timestamps for future events.

If you store local time + timezone name, the stored time doesn't have to change, and if you need it in UTC for display you can calculate it on the fly, using the most recent rules you know.

If intervals are more important (e.g. do something every 30 minutes, or exactly every 24 hours), then UTC is better, or if you are recording events as they happen.

Re: Time to Dump Time Zones

#197

Post by foxylad »

We run a global booking service. Fixed timezones are simple to accommodate, but abolishing daylight savings would save me hours of scribbling clock faces.

The issue is that when someone books a given time across a DST change, you need to adjust the unix timestamp in the right direction. And in my experience, your first guess at the direction is always wrong - even if you know your first guess is always wrong.

Still, I guess that making a few developer's lives easier is less important than saving several lives a year due to reduced pedestrian deaths.

Re: Time to Dump Time Zones

#198

Post by grzm »

detaro wrote: post #196
grzm wrote: post #192

Earlier quoted context omitted.

I can see how this could work for recording timestamps as they happen, or for events that have already happened. In this case, you still need to keep around the tables of time zone changes if you ever want to compare two timestamps. How do you handle future timestamps when time zone data changes? Update all future timestamps? Keep a separate timestamp recording the timestamp at which the future timestamp was last upd…

That's exactly the point, but the other way around. If the timestamp is defined in local time (e.g. "a meeting is scheduled for 15:00 every second thursday") and you generate a list of the next events as UTC, and then the DST rules change, you have to go in and fix all the UTC timestamps for future events. If you store local time + timezone name, the stored time doesn't have to change, and if you need it in UTC for d…

You're right. For future events it does make sense to record the local time zone. Thanks for the clear explanation.

Re: Time to Dump Time Zones

#199

Post by roel_v »

maxerickson wrote: post #194
roel_v wrote: post #178

Earlier quoted context omitted.

Because there are only 12 major divisions on a clock. An analog clock, that is. It reads the same at 3am and 3pm. So from that pov it only makes sense to call it the same.

There are also analog clocks with 24 divisions. https://en.wikipedia.org/wiki/24-hour_analog_dial I guess 12 hour clocks are an easy trick to make them easier to read and manufacture and so on.

Sure, as a novelty. Who here has ever seen one like that in the wild? And yes, I think 24 is much harder to read, and not necessary either - in those situations where you don't know (when looking at a clock) whether it's 3am or 3pm, you have much bigger issues to worry about :)

Re: Time to Dump Time Zones

#200

Post by swiley »

pfarnsworth wrote: post #29

Getting rid of Daylight Savings makes complete sense, and it's something we should really pursue. Getting rid of Time Zones is ridiculous. People know that 6am roughly is morning, and 6pm is roughly the evening. When you're dealing with someone internationally, you know not to call them at midnight their time because there's a high probability they may be sleeping. Having time roughly follow a standard around the wor…

The time the sun rises and sets drifts around (and drifts differently depending on how far north you go). It's really a separate thing that you should have an almanac (or an approximate expression) for.
Post reply on HN