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

Some Notes About Time

unix4lyfe.org

Post reply on HN
Print view View original

101–110 of 118 posts

Re: Some Notes About Time

#101

Post by ProblemFactory »

sla29970 wrote: post #93
ProblemFactory wrote: post #55

Earlier quoted context omitted.

> Also, does the problem that the leap second solves actually warrant all of the problems that it causes? Definitely not. The only benefit of leap seconds is keeping UTC in sync with solar time: the sun is highest in the sky at 12:00 noon at Greenwich. But in the modern world, synchronizing solar time and clocks to <1 minute is of no value to anyone but nostalgic astronomers.

Some delegates to the ITU-R process have argued in the above fashion. Other delegates have come representing countries which want UTC to remain as a valid count of days in the calendar (for 86400 SI seconds is not the same as one rotation of the earth). For over 10 years these two viewpoints have been at stalemate with no progress toward any compromise that might alleviate the problems that POSIX systems face at each…

I would argue for both fixed UTC based on atomic clocks, and 86400 seconds per day - at the expense of rotation of Earth not being in sync with UTC or calendar boundaries.

It will take 3000 years before leap seconds add up to an hour, but most countries adjust the clocks that much every year for DST. It will take 40000 years before the usual daytime hours turn into night, and by then I hope a single planet's rotation is a historical oddity.

Re: Some Notes About Time

#102

Post by jtheory »

ianburrell wrote: post #95
RyanZAG wrote: post #30

Earlier quoted context omitted.

Why can't you use intervals in a smart way? Single number is the easiest and fastest method to use for intervals. The only true problem with storing unix time is leap seconds and relativistic effects, which can both be safely ignored for most time keeping usages.

PostgreSQL intervals are smarter than just number of seconds between two datetimes. They can represent "1 month" or "1 year" which can't be represented as a number of seconds. Also, intervals can be used between dates or times, not just datetimes.

Exactly right; date arithmetic is horrible if you only have seconds to work with.

Even just saying "24 hours from now" -- as your user would see it -- you'll sometimes get the wrong answer if you just add on 24 hours worth of seconds... suppose they have a DST shift tonight?

What if you need to know how many days remain from today to March 1st of this year? ...well, are we in a leap year?

Postgres datetime doesn't solve all of the problems that crop up, but it's certainly better than using unix time.

Re: Some Notes About Time

#103

Post by Dylan16807 »

masklinn wrote: post #78
Dylan16807 wrote: post #63

Earlier quoted context omitted.

You're forgetting to factor in accuracy/resolution. TAI is completely perfect down to the picosecond level and further. That means you do have the number of actual seconds, milliseconds, microseconds, nanoseconds... You only encounter issues with TAI once you get down to femtosecond or smaller levels.

> TAI is completely perfect down to the picosecond level and further. I may have worded it badly, let's try again: TAI is "completely perfect" for the approximation it is: time elapsed at the geoid, which is a theoretical construct. That's an approximation for both "experienced time" and for anything which could be called "absolute time"

Oh that's easy to solve. Just mandate everyone live at sea level.

Re: Some Notes About Time

#104

Post by ProblemFactory »

albertzeyer wrote: post #28

This topic comes up again and again. But I mostly read only about the problems, not about the solutions. This post advises to use Unix timestamps. That's already what I'm doing mostly everywhere. And it seems to me like most people do and like this is somewhat accepted as the best available option - but still not perfect. Then I am wondering again: Isn't there really a perfect solution? Esp., the problems with Unix t…

> This of course still doesn't solve anything about synchronization or inaccurate system clocks but it would be better than Unix times.

One of the solutions used in various systems from cash machines to databases is to use GPS time. All GPS satellites carry atomic clocks, and when positioning the receiver also determines local time at accuracy up to 10 nanoseconds.

GPS time does not have leap seconds, and is always at a 19 second offset from TAI. It's available without a network, and without synchronization between computers.

Re: Some Notes About Time

#105

Post by T-hawk »

Dylan16807 wrote: post #103
masklinn wrote: post #78

Earlier quoted context omitted.

> TAI is completely perfect down to the picosecond level and further. I may have worded it badly, let's try again: TAI is "completely perfect" for the approximation it is: time elapsed at the geoid, which is a theoretical construct. That's an approximation for both "experienced time" and for anything which could be called "absolute time"

Oh that's easy to solve. Just mandate everyone live at sea level.

And stop the Earth from spinning, so we can get rid of that pesky oblateness and gravitational delta between the equator and poles.

Re: Some Notes About Time

#106

Post by mmahemoff »

Dylan16807 wrote: post #69
btipling wrote: post #56

Earlier quoted context omitted.

Your API should return Unix time. The end.

Because when someone wants millisecond resolution the best answer is an integer number of seconds, right? mmahemoff, are you using actual milliseconds, which means you have to keep track of leap seconds?

In my case, that level of precision isn't the consideration. I'm just expressing Rails' created_at and updated_at fields as integers instead of ISOs.

Re: Some Notes About Time

#108

Post by defrost »

natural219 wrote: post #47
defrost wrote: post #13

Earlier quoted context omitted.

> Time is tricky but there is a simple fact: it exists such a thing as the number of actual seconds elapsed since 'time x' (typically the Unix epoch but anything else will do too). Yeah. Hmm. Clearly an opinion expressed without either reading, comprehension, or experience. Why would I say that? Well, consider your statement about "actual seconds elapsed since epoch". Leaving aside the fact that Unix Time enumerates…

I can't interpret this as anything other than nitpicky. Are you suggesting that every programmer should know about relativistic effects of time dilation in controlled scientific experiments? I don't doubt that you have valuable experience and information to lend to the discussion, but your frame seems aggressively negative towards the OP with no discernible reason.

I posted shortly before midnight my time so excuse the delay in replying.

The OP article suggests that UnixTime is the answer for every programmer. My take home message to every programmer that uses UnixTime is to be aware that it's non linear and has hiccups that will bite them every few years if not taken into account. This is not so much aggressively negative as it is a simple statement of fact garnered from years of experience.

My message to every programmer that works in a distributed system is that they should read "Time, Clocks, and the Ordering of Events in a Distributed System" (Lamport 1978) which uses observations and arguments from relativity to comment on the manner in which events propagate outwards from sources.

As for limiting awareness to "controlled scientific experiments", no, I'm not advocating that at all as time slip (something that has many causes outside of dilation) pops up all over the place these days, for example many things rely on GPS time which is something else that is non linear and periodically updated. I'd suggest that anyone writing software that relies on second / sub second granularity should be aware of where their fiducial time marks come from and what hiccups there are in that system.

Re: Some Notes About Time

#110

Post by nathanstitt »

justincormack wrote: post #49
nathanstitt wrote: post #34

Earlier quoted context omitted.

Sometimes I think Mysql has corrupted everyone's brain. Postgresql and every other database that I'm aware of stores dates internally as a 4 or 8 bit number anyway, so you aren't saving anything by using an (hopefully) bigint instead of a datetime column.

I hope you meant 4 or 8 bytes not bits....

Yes, bytes. I suppose most everyone wants to use dates more than 256 seconds past Jan 1, 1970. cue embarrassment
Post reply on HN