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

301–310 of 321 posts

Re: UTC Is Enough for Everyone, Right?

#301

Post by btilly »

zimmund wrote: post #292
btilly wrote: post #142

Earlier quoted context omitted.

The Earth's rotation is slowing down. In a few hundred years with the current system, we will need more than 1 leap second per 6 months. How many centuries is hard to tell, since it is affected by many things, including global warming.

source?

https://www.seeker.com/ice-age-clues-help-explain-mysterious... is one of many.

Note that if the day slows by 5.5 ms from 24 hours, then we need an average of more than one leap second per 6 months to keep up. Per https://en.wikipedia.org/wiki/Earth%27s_rotation the Earth's rotation changed by 1.7 ms in the last century, an average of 2.3 ms in last thousand, and it is being affected by a variety of causes right now.

Re: UTC Is Enough for Everyone, Right?

#302

Post by caf »

ithkuil wrote: post #271
caf wrote: post #236

Earlier quoted context omitted.

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.

I think I'd resolve it by saying that any bookings made in a timezone that has changed its definition will be cancelled if the new definition causes the booking to conflict with another (including the case where two or more timezones have changed simultaneously: all involved bookings attached to changing timezones are cancelled).

"The timezone you have used to define this booking has been altered, and the booking cannot be updated due to unavailability of the resource XXXX. Please choose a new time for this booking."

Re: UTC Is Enough for Everyone, Right?

#303

Post by HankB99 »

dev_north_east wrote: post #276
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...

Only slightly. Changing the orbit of the earth to achieve a 333.333 day year is not feasible b y any foreseeable technology.

Re: UTC Is Enough for Everyone, Right?

#304

Post by zamalek »

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…

Some timezones change twice a year. Seriously![1] A fellow engineer was responsible for the web front-end framework for dealing with time (back when we built it all here) and he spent months working through some of the strangest crap, some JS, some wierd crap humans dream up.

Good example: you, user A, are in a TZ that switches biannually - at one point in the year you lose an hour, at another you experience an hour twice. Now, another user B is also in one of these whacko places and creates a meeting (while experiencing an hour for the second time) or what-have-you for a future time where user A goes through their local groundhog hour. You have a backend server that, for legacy reasons, simply truncates TZ and goes with its own local TZ. That server is in another TZ that has an identity crisis. JS is doing dumb stuff that only JS could do. Does your brain hurt yet? I'm pretty sure that this engineer can now perceive four dimensions.

He didn't receive a bug report until we migrated to UTC. UTC made things worse, somehow. As it turns out UTC is only good for when you care about a machine doing something at some time, or when working relationally.

Store TZ (ideally location, an offset is not a TZ) along your dates. When presenting them include that information, as well as relational ("3 days, 4 hours ago at 00h15 in WA").

Time is nuts.

[1]: https://en.wikipedia.org/wiki/Daylight_saving_time

Re: UTC Is Enough for Everyone, Right?

#305

Post by daveFNbuck »

mseebach wrote: post #285
daveFNbuck wrote: post #282

Earlier quoted context omitted.

This is how you use today and tomorrow. It's not universal to all human language or even to English speakers. Words have different meanings depending on lots of factors including context and region. Your definition has the same issue that mine does, just with sunrise being the time around which the meaning of tomorrow is unclear. How high does the sun have to be before "today" becomes defined and the meaning of "noon…

Yes, there's ambiguity, but there's no reason to introduce new ambiguity where none existed before by trying to reason about these words in terms of midnight (possibly for the benefit of computers), when that was never where these words were anchored. That was the point I was trying to make.

I've always reasoned in terms of midnight because that's when the date changes. I use tomorrow to mean the next date and today to mean the current date. I'm not doing it for the sake of computers, that's just what I've always understood these words to mean.

I think using midnight as the anchor for the today/tomorrow distinction is a lot less confusing and ambiguous than having today/tomorrow not tied to the current date.

Re: UTC Is Enough for Everyone, Right?

#306

Post by dang »

henrikschroder wrote: post #299
snarf21 wrote: post #278

Earlier quoted context omitted.

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

https://qntm.org/calendar Your idea will not work. Here is why: (X) "7am" is a social construct (X) social constructs are actually very important (X) the day of the week shouldn't change in the middle of the solar day (X) this would further ambiguate the word "day" (X) local "midnight" should be the middle of the local night (X) timetables would become unreadable (X) nobody would agree to pick your time zone over the…

Personal attacks will get you banned here. Please don't do that again.

Also, please don't post snarky comments in the first place. This is in the site guidelines as well: https://news.ycombinator.com/newsguidelines.html.

Re: UTC Is Enough for Everyone, Right?

#307

Post by fphilipe »

ssijak wrote: post #60
jeremyevans wrote: post #52

Earlier quoted context omitted.

> I'd just like to point out that a lot of RDBMSs support storing date and time alongside timezone information directly without using two separate fields. SQL Server has datetimeoffset, PostgreSQL has timestamp with time zone, and Oracle has timestamp with time zone. PostgreSQL's "timestamp with time zone" doesn't store timezone, it converts the time to UTC and stores that, and on retrieval converts the value to the…

That sounds dumb (if column type is called like that text in the quotes)

Might sound "dumb" or confusing (which it is), but makes a lot of sense. I've written a post explaining the difference between "timestamp with/without time zone": http://phili.pe/posts/timestamps-and-time-zones-in-postgresq...

Re: UTC Is Enough for Everyone, Right?

#308

Post by cup-of-tea »

foobar1962 wrote: post #180

> [1883] ... a bunch of rich, white railroad tycoons met at a fancy Chicago hotel to agree on a standard timezone so their trains would work better together... The Brits did this for their railroad in 1847. Time balls were used to synchronise clocks before telegraph and radio. https://en.wikipedia.org/wiki/Time_ball On clock accuracy, I was reading last night about time dilation due to gravity, and the difference in…

Indeed, I thought it was well known that Britain was the first to standardise time and that it was done for the railway.

Re: UTC Is Enough for Everyone, Right?

#309

Post by taejo »

blunte wrote: post #42
captaincrowbar wrote: post #39

Earlier quoted context omitted.

"You advocate a ________ approach to calendar reform..." https://qntm.org/calendar

Until software is uniformly correct with respect to timezone rules and auto-location-updating, there will be more problems with the current system than there would be with a fixed UTC-only system. I'll take "better" even if better != perfect.

Most people's lives don't revolve around software. Software is a tool that shouldn't require turning people's lives upside down to work in its way.

Re: UTC Is Enough for Everyone, Right?

#310

Post by jasonwatkinspdx »

dpark wrote: post #215
jasonwatkinspdx wrote: post #197

Earlier quoted context omitted.

> Probably not. This explanation of duodecimal is really farfetched and I’m pretty sure it arose from someone staring at their hands desperately trying to come up with a way to count 12 on their fingers to explain this. You are mistaken. Finger counting by using your thumb against one of the 12 segments of your fingers is common in many asian cultures. It's utterly simple and immensely practical as it allows you to c…

That is an interesting fact I wasn't aware of. I have doubts about the actual relevance of this, though. e.g. Chinese seems (so far as I can tell) to have always used decimal numbering systems, making this essentially a clever counting trick.

"I had no idea this thing even existed but let me continue to tell you why it's inferior"
Post reply on HN