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

111–120 of 321 posts

Re: UTC Is Enough for Everyone, Right?

#111

Post by jandrese »

welterde wrote: post #76
milesvp wrote: post #38

Earlier quoted context omitted.

Right? And that that 37 second offset will change from year to year? I was waiting for the bombshell, that some minutes actually have 61 seconds in them, and some have 59 seconds (though it occurs to me that I don't know if astronomers ever add or subtract more than a second for any given clock adjustment).

The goal is to always keep UTC within one second of UT1. Short of very drastic events I don't think it will ever be neccessary to introduce more than one leapseconds in a fairly long time interval. And even if it was, I would think that they would do seperate leapseconds events some time apart.

There are two official primary times a Leap Second can occur. December 31 and June 30. There are provisions for more slots, but they're not really expected to ever be used.

Like most things associated with time Leap Seconds are a huge headache to implement properly on computers. If you want some fun watch what various NTP servers around the world do when Leap Seconds roll around. You will see clocks that start to drift for 15 minutes before jumping to the right time, some that wait until 8AM local time on the following day to correct, and some that just go crazy. And of course you have Google's clock smearing across most of a day.

IIRC there was one major earthquake that caused a sooner than expected Leap Second adjustment.

Fun fact: GPS, NTP, and many similar timing formats have flags in the signal that warn clients of upcoming leap second events. Few receivers pay attention to them however.

Re: UTC Is Enough for Everyone, Right?

#112

Post by flarg »

jameshart wrote: post #84
da_chicken wrote: post #47

> Properly storing timezone-aware times 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. I think MySQL does as well, but I seem to recall something strange about it. Or maybe that's just me expecting MyS…

Erp. This sentence made me wince. Times don't have timezones - places have timezones. The idea that time handling is made easier by attaching timezones to times is the cause of so many headaches. Correct time handling involves understanding place - the place where things happen, the place where the user is observing them from, the place where a clock displays a particular time.

I guess it depends on if the event concerned only happens at one place, such as a clinical site visit, or many places, such as a global call

Re: UTC Is Enough for Everyone, Right?

#113

Post by em500 »

captaincrowbar wrote: post #39
blunte wrote: post #16

Sadly I didn't have enough time to read the whole article... But I wish we could all just use one time. For some, midday would be 12, and for others it might be 19, but we already all use the same dates regardless of whether February is winter for one location or summer for another.

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

Even more on point: https://qntm.org/abolish

Re: UTC Is Enough for Everyone, Right?

#115

Post by sp332 »

vorg wrote: post #97
sp332 wrote: post #3

Earlier quoted context omitted.

There are tons of autoplaying videos, and each one takes a few % of my CPU. The biggest difference for me was the one just after the heading "Who needs December 30, 2011 anyway". Turning off autoplay (e.g. media.autoplay.enabled in Firefox) fixed it. You can still play each video by right-clicking on it.

The autoplaying videos are a pain, I couldn't find "media.autoplay.enabled" in my Preferences menu in Firefox, and this in the article calling me "clueless" doesn't help: > it is predictable that some clueless commenter on Hacker News will complain that this page has autoplaying video on it

Type about:config into the address bar and then search in there.

Re: UTC Is Enough for Everyone, Right?

#116

Post by ivanhoe »

bad_user wrote: post #78
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…

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…

The meaning of the date will not change compared to the UTC absolute coordinates, but usually users care only about their local time. If you set an alarm to wake you up at 8:00, you expect it to ring at 8am your time every day. What if in future user's local time zone gets changed - say if daylight savings are abandoned, as many countries consider doing - The user might not be in +2 offset anymore and when you convert it to the local time the alarm will ring at 7am or 9am instead of 8:00. It's definitely not what user would expect.

Re: UTC Is Enough for Everyone, Right?

#117

Post by da_chicken »

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)

Why? If you're doing things correctly, you don't need to specify data types particularly often in SQL. You specify it once when the table is created and that's it. All you care about on the programming interface is that your application knows what data type of your language to use with each data column. What's wrong with a verbose and descriptive name for a data type?

Re: UTC Is Enough for Everyone, Right?

#118

Post by hanikesn »

cryptonector wrote: post #62
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…

Yes, you have to periodically recompute times. For example, if you store time in TAI then you'll have to recompute all other future times as leap seconds are announced.

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

Re: UTC Is Enough for Everyone, Right?

#119

Post by kbrackbill »

da_chicken wrote: post #117
ssijak wrote: post #60

Earlier quoted context omitted.

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

Why? If you're doing things correctly, you don't need to specify data types particularly often in SQL. You specify it once when the table is created and that's it. All you care about on the programming interface is that your application knows what data type of your language to use with each data column. What's wrong with a verbose and descriptive name for a data type?

I don't think they're saying that having verbose name is dumb, I think it's that a type called "timestamp with time zone" doesn't actually store a time zone.
Post reply on HN