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

91–100 of 118 posts

Re: Some Notes About Time

#91

Post by CamperBob2 »

gnosis wrote: post #68
sla29970 wrote: post #52

Earlier quoted context omitted.

Getting a TAI timestamp is impossible because the BIPM (the authority that defines TAI) does not want TAI used for such purposes. Without approval from the authority nobody will undertake to construct the technology to provide TAI to an operational system. Without a source for TAI, any system which claims to be using TAI is making the same mistake that POSIX made with UTC. To wit: Creating a new thing which has the n…

Why doesn't BIPM want TAI to be used for timestamps?

TAI is calculated in retrospect, as I understand it, based on the weighted contributions of the atomic timescales maintained by all of the participating countries. As a result, if you store a TAI timestamp in hopes of using it as an absolute time reference point, you will have to go back and update it when BIPM releases the next 'Circular T' bulletin (http://www.bipm.org/jsp/en/TimeFtp.jsp?TypePub=scale).

Re: Some Notes About Time

#92

Post by sla29970 »

Dylan16807 wrote: post #73
wereHamster wrote: post #5

Earlier quoted context omitted.

Also, there have been many definitions of UTC, GMT etc over time. So to be truly correct you'd always have to mention which definition of UTC you are referring to when you use the term. And the ITU-R is debating to redefine UTC once again and remove leap seconds ( http://www.ucolick.org/~sla/leapsecs/ ). If you are really interesting in the time stuff, here is a great resource: http://www.ucolick.org/~sla/ .

>mention which definition of UTC you are referring to Doesn't the time value tell you? Or have there been temporally overlapping definitions of UTC that disagreed?

There have been many defintions of UTC http://www.ucolick.org/~sla/leapsecs/timescales.html#UTC which do not agree. When an API does not match what the providers supply, which definition qualifies as "official"?

Re: Some Notes About Time

#93

Post by sla29970 »

ProblemFactory wrote: post #55
InclinedPlane wrote: post #12

Who was the genius who decided that unix time should handle leap seconds? It seems like such an obviously bad idea. The biggest advantage of unix time has always been that it is monotonically increasing and that it is precisely defined as seconds since the epoch, period. And then all of that is now broken because of this decision. Also, does the problem that the leap second solves actually warrant all of the problems…

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

Re: Some Notes About Time

#94

Post by tekromancr »

tommorris wrote: post #51

Time is even more complicated than that because of vagueness, either intentional or unintentional. Humans represent time vaguely rather than precisely. Computers tend not to. A while back, the British Library catalogue was put online as linked data. The library cataloguers had added details of author birth and death years but not always birth dates . But the data model normalised "1941" to "1941-01-01". (They fixed i…

Now take it a step further and think one if the problems I ran into when working on MeNomNom about the hours of operation for bars/night clubs. They might list their hours as Mon-Thur 6pm-1am, Fri-Sat 6pm-3am. That's also how people expect to view the hours, but the fact is that it is incorrect. The actual hours (That I had to store in the DB) were more like Monday 6pm-11:59:59pm, Tuesday 0:00:00am to 3am, Tuesday 6pm-11:59:59pm. Human representations of time are so wonky! People seem to have an intrinsic sense that another day doesn't start until they sleep.

Re: Some Notes About Time

#95

Post by ianburrell »

RyanZAG wrote: post #30
lysol wrote: post #24

> When storing time, store Unix time. It's a single number. Don't do this in your database. Use your datetime types. Please. You might save some work with your timezone but you're not going to be able to use intervals etc in a smart way. This would be even dumber with PostgreSQL, which has much more robust date/time functionality (being able to use the - operator with datetimes and intervals, for example) and complet…

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.

Re: Some Notes About Time

#96

Post by mongol »

Maybe the most insidious "bug" I ever had to solve: a performance test environment showing very strange behavior. Eventually I found that time jumped 30 seconds forward every minute, and soon after 30 seconds backward every minute. Had some kind of redundant time servers configuration, messing time up. Took longer to find out than seems reasonable, but it is the kind of thing you don't really expect.

Re: Some Notes About Time

#97

Post by jtheory »

mikeash wrote: post #21
InclinedPlane wrote: post #10

Earlier quoted context omitted.

I think you mean that unix time is seconds since the epoch minus leap seconds.

All depends on what sign you assign to the leap seconds!

Ah, but negative numbers are not included in the set of counting numbers, and your initial comment referred to "the leap seconds" with no reference to "the leap second offset" or other verbiage that might imply anything other than a simple count of leap seconds.

Alas, I'm afraid you've no other option but to admit a minor error, as traumatic as that may be.

Re: Some Notes About Time

#99

Post by mikeash »

jtheory wrote: post #97
mikeash wrote: post #21

Earlier quoted context omitted.

All depends on what sign you assign to the leap seconds!

Ah, but negative numbers are not included in the set of counting numbers, and your initial comment referred to "the leap seconds" with no reference to "the leap second offset" or other verbiage that might imply anything other than a simple count of leap seconds. Alas, I'm afraid you've no other option but to admit a minor error, as traumatic as that may be.

I'll never admit to an error, although perhaps a negative value for correctness.

Re: Some Notes About Time

#100

Post by jtheory »

sopooneo wrote: post #46
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…

I'm a noob. How can two equal timestamps represent different times? Or do you just mean as presented in different timezones?

Because of the leap seconds -- the unix time would show the same time for those two seconds (before/after the leap).
Post reply on HN