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

UTC Is Enough for Everyone, Right?

zachholman.com

Post reply on HN
Print view View original

271–280 of 321 posts

Re: UTC Is Enough for Everyone, Right?

#271

Post by ithkuil »

caf wrote: post #236
ithkuil wrote: post #235

Earlier quoted context omitted.

> [..] regularly scheduled meeting time specifically to the UK or to the US very funny things happen when there is a shared physical resource e.g. a booked meeting room, and you have a bunch of people schedule meetings with different reference time zones. ah, and if you think this creates havoc only for a the few weeks while the TZs are out of sync, remember that in the southern hemisphere DST is applied in "reverse"

Oh, that's fun: "A change in the definition of a timezone has caused previously non-conflicting bookings to conflict."

well, technically the "funny" aspect I was talking about, was the things that happened once the meeting room booking has conflicted and two group of people clashed both claiming that their booking was more right (as opposed to "how funny this can happen" in the first place).

It's also interesting that since this doesn't happen frequently enough it's usually hard to develop a good way to get out of it.

Re: UTC Is Enough for Everyone, Right?

#272

Post by cesarb »

leonroy wrote: post #156
0x0 wrote: post #33

So the article seems to imply you should store all timestamps as UTC (with an additional timezone string ID). But for events in the future that needs to happen on a specific "wall clock point in time", it might be better to actually store the yyyy-mm-dd hh:mm:ss as a string with a timezone next to it, because timezones can and do change often unpredictably. If you pre-calculate what "4.00pm next August 1st" is as a U…

We spent weeks on this for our new conference calling app to determine when a user says "Setup a call at 10am for my group every week" that come October 29th 2018 the call takes place at 10am, not 9am following a DST change. After a heckuva lotta research and reading we determined that we needed to store the scheduled meeting time using two values; the local datetime and the desired timezone eg. scheduledAt: 2018-05-…

> store the scheduled meeting time using two values; the local datetime and the desired timezone

How does that work when the same local datetime happens twice during a DST switch, or when a local datetime is skipped during the other side of a DST switch?

Re: UTC Is Enough for Everyone, Right?

#273

Post by HankB99 »

Probably not a good time to propose decitime, I guess. (No pun intended.)

Day is the basic measure. Deciday = day/10. (=~ 2.4 hour) Centiday = day/100

Either could be used in place of the old fashioned hour.

Milliday = day/1000 (=~ 84 seconds)

Milliday seems like a good replacement for the traditional minute.

Centimilliday to replace seconds? It's a but unwieldy but could be abbreviated as cmd (similar to the commonly used 'sec.')

Years are a little troublesome. However with sufficient energy input a Kiloyear could be made to be 3 years. With sufficient precision (and perhaps occasional correction) it could resolve that leap year and occasional leap second issue.

There would be some ramifications. For example the Newton is defined in terms of seconds so there are some units beyond pure time that would also require revision.

Let's get rid of this madness of 24 hours, 60 minutes and 60 seconds. And 365.2425 days was just plain wrong from day 1.

Re: UTC Is Enough for Everyone, Right?

#274

Post by cryptonector »

wafflebear wrote: post #263
cryptonector wrote: post #165

Earlier quoted context omitted.

"One month from now" is horrible. Is that "30 days from now" or "same day number next month"? If the latter, then how do you handle a 31st when the next month has 30 days or fewer? (Or a 29th when the next month is February and this is not a leap year?) This is a difficult subject. Recurrence is especially tough to model in a database.

How about adding the number of days in the current month?

It depends on user intent.

Often the user means "same day of the week, four or five weeks from now".

Re: UTC Is Enough for Everyone, Right?

#275

Post by cryptonector »

tialaramex wrote: post #244
perl4ever wrote: post #226

Earlier quoted context omitted.

I don't understand why you say leap seconds have nothing to do with wall clock time. Don't wall clocks include leap seconds?

Wall clocks just track UTC. Today they have leap seconds because we defined UTC to include leap seconds, tomorrow if UTC or a replacement universal time no longer has leap seconds then wall clocks won't have leap seconds.

But then people will notice a few decades later that noon in UTC-minus-leap-seconds is not noon.

Re: UTC Is Enough for Everyone, Right?

#276

Post by dev_north_east »

HankB99 wrote: post #273

Probably not a good time to propose decitime, I guess. (No pun intended.) Day is the basic measure. Deciday = day/10. (=~ 2.4 hour) Centiday = day/100 Either could be used in place of the old fashioned hour. Milliday = day/1000 (=~ 84 seconds) Milliday seems like a good replacement for the traditional minute. Centimilliday to replace seconds? It's a but unwieldy but could be abbreviated as cmd (similar to the commonl…

I can't tell if you're being serious...

Re: UTC Is Enough for Everyone, Right?

#277

Post by scbrg »

Asooka wrote: post #250
matt-tingen wrote: post #172

Earlier quoted context omitted.

Even something as simple as "tomorrow" can be ambiguous. I often ask my phone to set a reminder for tomorrow. If I'm asking after midnight, what I really mean is "today" since I haven't gone to sleep yet. Google seems to get this right, thankfully.

Tomorrow is tied to the morrow, so it isn't tomorrow until sunrise.

So in roughly 1200 hours then. Check.

/folks up north

Re: UTC Is Enough for Everyone, Right?

#278

Post by snarf21 »

henrikschroder wrote: post #208
snarf21 wrote: post #27

Earlier quoted context omitted.

I completely agree. It isn't like we don't deal with this already planning a flight to/from Vegas or having a call with someone on the other coast. Plus we can also get rid of the abomination that is daylight savings. I think there is a simple plan that isn't disruptive. Simply require that all times be listed in both formats. For example, 9:00 am EDT (13:00 UTC) for all printed times on all signs, etc. moving forwar…

> Eventually, we can drop the first as people adjust. This doesn't help in any way, shape or form. You have pissed off billions of people who have had to re-learn custom times for things, you have caused the weekday to flip in the middle of the day for billions of people, and you STILL haven't solved the problem of "Can I call Uncle Steve in Melbourne, or is he sleeping right now?" https://qntm.org/abolish

No one has to be pissed off, they will slowly adjust and learn. Eventually people will only think in UTC. If that never happens then, leave both times. I think over time people will develop an intuitive sense of UTC the same way we do now for timezones but we lose all of the issues with having more than one truth.

There is no way to solve that problem of Uncle Steve (imo). But there is no difference in saying Steve is +8 hours so our noon is his 20:00 and or saying we should only call Steve between 03:00 and 20:00 UTC. It is an offset either way. It is only jarring to think that way now because it is the one way people have.

There is also the problem of someone driving across the US and suddenly they pass an invisible line and now it is one hour in the past or the future. The day changing while you work already happens for everyone working 3rd shift.

Billions of dollars in waste and confusion happen today because of forgetting about timezones. One study suggests that international trade is decreased by 5% per timezone between countries.

Re: UTC Is Enough for Everyone, Right?

#279

Post by billysielu »

I've seen a few systems mixing up their clocks, sometimes using the database server clock, sometimes the web server clock, sometimes the user's local clock. Whatever clock you're using, be consistent about it.

Users can and do configure different time zones than where they're actually located, e.g. if someone in India is working with a team in the UK, they'll probably have Indian time on their local clock, but select UK in their user profile.

Also, some people travel.

Re: UTC Is Enough for Everyone, Right?

#280

Post by peterwwillis »

quickthrower2 wrote: post #202
peterwwillis wrote: post #133

Earlier quoted context omitted.

I always figured if spacetime was relative, why don't we just report the location we are at and that local time? If I know I was in Lower Manhattan at 2:00pm on November 19th, 2007, somebody else can just do a little math to figure out when that actually was compared to their own local time and place. All times are interpretive. UTC just seems like a giant hack to try to avoid the interpretation.

Who's clock is correct though.

Whatever the town clock is set to.

I'm surprised the author didn't mention Railway time. The standardization of time did not begin in the USA in 1883, it began in England in 1840. Before then, sundials, and later a local mean time, was used to determine local time. Railroads published almanacs with different local times, and instructions on how to reset a watch along a route to know what time it was. However, the small changes in time, or even differently timed sunsets, created problems and accidents, so to solve this they used the newly invented telegraph service along the railroad's telegraphic lines to synchronize clocks to the official time at Greenwich. This method to synchronize time then spread to India and then the United States. It was in 1880 that a law passed in Great Britain finally made the new time official across the whole country.

However, as the attached article shows, neither GMT nor UTC solve everything. When humans are involved there will always be mistakes unless things are simplified for them.

Post reply on HN