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

221–230 of 321 posts

Re: UTC Is Enough for Everyone, Right?

#221

Post by blockchain-help »

Blockchain has shown its usefulness when recording events like transactions. This usefulness could be extended to medical records, which often suffer from inaccuracy and discrepancies.

Healthcare professionals are responsible for ensuring that sensitive medical records are accurate, complete, and only available to authorized individuals. All of this can prove to be difficult when healthcare providers all have different systems for storing information. TO KNOW MORE PLEASE CHECK OUR SITE:- http://www.blockchainhelp.pro

Re: UTC Is Enough for Everyone, Right?

#222

Post by exikyut »

zifnab06 wrote: post #206
saagarjha wrote: post #152

Earlier quoted context omitted.

> It’s so predictable that developers will pooh-pooh having to write timezone code, almost as much as it is predictable that some clueless commenter on Hacker News will complain that this page has autoplaying video on it. And then someone will calmly quote this passage in response, quietly pleased with themselves that the initial commenter was rude and certainly didn’t read the post at all. Then a third person will c…

The author played us all like a fiddle.

He's playing my laptop like a fiddle, too, a really high-pitched one: all the videos are keeping the CPU at 100% CPU so I had to downclock everything to keep the system below 64°C.

So: the first time I ever found a paragraph like the one the GP has quoted, happened on the same site I've ever been on where the autoplaying videos are making my whole system (including typing this comment) lag worse than any other site I've been on.

At least it gave me one good idea for the Extension I'm Making One Day™: watch the CPU and if the current page is killing it and it has autoplaying videos and/or CSS animations, automatically kill both.

In the meantime, I had to close the article as it was unreadable. (Wow, getting my low typing latency back is wonderful!)

Re: UTC Is Enough for Everyone, Right?

#223

Post by sudhirj »

Neeek wrote: post #220
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…

I might not be understanding your scenario correctly, but isn't it stated that UTC has 00:00 offset and should be stored that way? You would then add an offset based on current tzdata for that timezone string which would make it dynamic and accurate for the situation you described.

There's two distinct things at play here - storing times in the past and present, and times in the future.

For the past and present, UTC is fine, and a source timezone if necessary. To track the exact instant when something happened to me, just storing UTC is fine. If I want to know what where the hands on my clock were when that happened, you also store which clock I was using separately (timezone), but this is optional and doesn't prevent accuracy.

For future times, relating to humans, like on a calendar, there's a very important distinction - I want to set appointment when my clock shows a certain time, irrespective of what the timezone rules (Daylight saving time rules can change) are at that point. Here, storing the UTC time for my appointment according to today's rules is a problem - you must simply store what I expect to see on the clock and apply the timezone rules lazily at the last possible minute.

Re: UTC Is Enough for Everyone, Right?

#224

Post by waterhouse »

_asummers wrote: post #182
dpark wrote: post #175

> If you're like me and immediately said ohhhhhhhhhhhh, so THAT'S why there's twelve hours in a day! and immediately followed it up with: wait, why the fuck are they using twelve instead of ten? ... > It's most likely because you have twelve joints in your hands: three in each of the four fingers, excluding the thumb. I thought that was pretty nifty to discover. Like, I had never looked at my hands before, really. Ha…

I might not be remembering my History of Math correctly, but my recollection is that the Babylonians used Base 60, and 12 is an even subdivision of that. I also recall other Asian number systems having base 12 in some capacity, so there may be something to the counting methodology he outlined if it showed up in a few separate parts of the world. Counting that way on one hand and then using the other hand to tally the…

Wiki[1] seems to support your last sentence's description of how base 60 appeared.

Now, that approach would guarantee that your base is a product of two numbers (# fingers * # bones on non-thumb fingers). And, if your non-thumb fingers are roughly equivalent to each other, then that would guarantee it's a product of three numbers (# fingers * # non-thumb fingers * # bones per non-thumb finger). So I would say "it's a product of lots of numbers" does have a lot to do with the origins of base 60. Base 10, of course, is (# hands * # fingers per hand). Base 12 being more factorable than base 10 is just the luck of getting 3 * 4 vs 2 * 5.

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

Re: UTC Is Enough for Everyone, Right?

#225

Post by perl4ever »

cryptonector wrote: post #159
hanikesn wrote: post #118

Earlier quoted context omitted.

I don't think I ever heard of anyone (besides scientists) to store timestamps in TAI. Though Ada supports leap second calculations in the standard library: http://www.adaic.org/resources/add_content/standards/05rat/h...

Dealing with time well into the future is rough because of the unknown timezone changes and unknown leap seconds. There's not much you can do. Computing future times in TAI from user inputs in wall clock time is fraught, so I guess you can't store TAI in those cases. For a calendar app, since users want to deal in wall clock time, you have to store time with timezone and with leap seconds (so UTC + time zone). And yo…

Times in the future being problematic reminds me of the quote attributed to Neils Bohr:

"it is very difficult to predict — especially the future."

Re: UTC Is Enough for Everyone, Right?

#226

Post by perl4ever »

tialaramex wrote: post #178
cryptonector wrote: post #159

Earlier quoted context omitted.

Dealing with time well into the future is rough because of the unknown timezone changes and unknown leap seconds. There's not much you can do. Computing future times in TAI from user inputs in wall clock time is fraught, so I guess you can't store TAI in those cases. For a calendar app, since users want to deal in wall clock time, you have to store time with timezone and with leap seconds (so UTC + time zone). And yo…

"That scares me. Users really need wall clock time." Why would getting rid of leap seconds from UTC be a problem for that? The reason there are leap seconds is nothing to do with wall clock time, it's because some people feel the time ought to be intimately connected to the Earth's rotation, but the Earth doesn't oblige by rotating steadily. In my view the people demanding this relationship be maintained ought to tak…

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

Re: UTC Is Enough for Everyone, Right?

#227

Post by perl4ever »

pathseeker wrote: post #108
bad_user wrote: post #78

Earlier quoted context omitted.

Actually the meaning of a date like: 2018-05-26T13:45:21+02:00 Will never change, regardless how many time zone changes you may have. What does change is the method to compute the time difference. So can you say how many days, hours, minutes, seconds ago that was from: 2043-02-12T11:15:16+02:00 You won’t be able to, because then you have to account for leap seconds, etc. Also “next Tuesday” does have to take into acc…

>Actually the meaning of a date like: 2018-05-26T13:45:21+02:00 Will never change, It will respective to the local time though if a state decides to stop honoring DST or changes TZ.

I once ran across a book of changes over time to local time zones, I believe for historical research. It was the size of a phone book.

Ah yes, American Atlas: United States Latitudes, Longitudes, Time Changes and Time Zones 5th Edition by Thomas G. Shanks 448 pages.

Covers probably well over 100K locations each with its own history of timekeeping.

Re: UTC Is Enough for Everyone, Right?

#228

Post by mirimir »

> UTC isn’t directly used by people (unless they’re really weird).

I find it best to stick with UTC. Otherwise there's too much ambiguity. Especially when we're all pretending to be somewhere that we're really not.

Re: UTC Is Enough for Everyone, Right?

#229

Post by acqq »

cryptonector wrote: post #164
leonroy wrote: post #156

Earlier quoted context omitted.

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

You also need to periodically compute the next event, but you can't do it too far in advance. You have to do it close enough to the event that that you can adjust to timezone definition changes. Hopefully you don't have to think about leap seconds.

Why would anybody schedule events in local time to happen on leap seconds?

Re: UTC Is Enough for Everyone, Right?

#230

Post by Iv »

Spooky23 wrote: post #204
Iv wrote: post #190

Earlier quoted context omitted.

> "wall clock point in time" The tricky thing to realize is that this is not a datetime. This is more of a contract/condition saying "when localtime will be at this value" or better yet "when localtime will have exceeded this value for the first time" because you know someone will put a date on a leap second or missing DST hour at one point.

It depends on the application and what the customer need is. My son’s friend in school was born on February 29. We could go through the time pedantry and claim that she is 1 year old (she is 6), or pick an arbritrary moment in time (say March 1, except for leap year) and get on with the party. If you’re plotting a satellite course, the details matter, but many, if not most use cases require consistency over precision…

If you are dealing with physics, like a satellite course, "wall time clock" is irrelevant. Wall time clock is a human construct that is ambiguous in many edge cases, dependent on position and local politics.

Indeed, your son's friend's age is an ambiguous notion, Hence the need of a more precise contract than a simple date.

Post reply on HN