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

71–80 of 118 posts

Re: Some Notes About Time

#71

Post by rmc »

NateEag wrote: post #26

As the article hints, even though timezones are usually presentation-only, there are some cases where business logic really does have to deal with timezones. If your software has business logic that cares about, say, what day a specific person perceived an event as happening, it needs to think about the timezone they have set. So, in such cases, you'd better keep a history of all the timezones they've ever chosen, an…

Agreed. Often you need to care about timezones. Someone wants an alarm to go off at 8am every day. Well you need to start thinking about timezones, since that "8am" needs to be local time.

Re: Some Notes About Time

#72

Post by rmc »

taeric wrote: post #45
TeMPOraL wrote: post #41

Earlier quoted context omitted.

But this will still be useless anywhere else than "locally". The timezone just became implicit and lost.

Of course, if you add a timezone, you are likely in trouble when daylight savings time comes/goes. That is, shows don't change times just because you effectively changed timezones.

Depends on how you're storing the timezone. If you store it as "UTC+2 hrs", then yes you'll have a problem. If you store it as the tzdata "Europe/Sofia", then it'll take care of all the timezones.

Re: Some Notes About Time

#73

Post by Dylan16807 »

wereHamster wrote: post #5
wereHamster wrote: post #3

He missed to explain TAI and its relation with the other times.

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?

Re: Some Notes About Time

#74

Post by rmc »

A good article, but the first point is (essetially) incorrect:

UTC: The time at zero degrees longitude (the Prime Meridian) is called Universal Coordinated Time (UTC).

If you stand at the Prime Meridian in London during the summer and ask someone what time it is, the correct answer will be one hour away from UTC.

Re: Some Notes About Time

#75

Post by nonamegiven »

patrickmay wrote: post #16

Erik Naggum's "Long Painful History of Time" ( http://www.scribd.com/doc/93991574/Erik-Naggum—ALongPainfulH... ) is well worth reading, too.

Working through it, thanks.

The link in the paper's headers is still live: http://naggum.no/lugm-time.html

The home page refers to his ill health: http://naggum.no/

And he in fact died in 2009 at 44: https://en.wikipedia.org/wiki/Erik_Naggum

Interesting guy, involved in specifying the Internet from link level to mid-email level, worked on Emacs, and among the first Usenet users to be known for flaming. I vaguely remember the name in that context.

On balance, a contributor.

Re: Some Notes About Time

#76

Post by nonamegiven »

chris_wot wrote: post #20
kator wrote: post #8

Funny I read the title and thought: TVM but then realized it was the age old quest for time keeping and dreaming of ways to track it with reasonable sanity.. :-) Bonus points for anyone who knows what I mean by TVM and can describe why every programmer should know about it..

I can only think of Time Value of Money...

Unfortunately Google can only think of that too.

Re: Some Notes About Time

#77

Post by rimantas »

Dylan16807 wrote: post #66
piqufoh wrote: post #62

"the Prime Meridian was (arbitrarily) chosen to pass through the Royal Observatory in Greenwich" At the International Meridian Conference in 1884 41 delegates from 25 nations met in Washington, D.C., USA and selected the meridian passing through Greenwich as the official prime meridian due to its popularity - not an arbitrary decision ;) However, the French abstained from the vote and French maps continued to use the…

How is a popularity contest not a shining ideal of completely arbitrary decision-making?

In this case popularity was the best criterion. Imaginary line is just that—imaginary line, no one is intrinsically better than other, so the one already popular was the best choice.

Re: Some Notes About Time

#78

Post by masklinn »

Dylan16807 wrote: post #63
masklinn wrote: post #7

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' Yes and no: it might just exist theoretically, but we have no way to get at it. The closest we have is TAI, which is only an approximation of the time elapsed at mean sea level on the earthly geoid, because clocks fall victim to gravitational time dilatation and compression. To accurately measure…

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"

Re: Some Notes About Time

#79

Post by rdtsc »

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…

> Computers tend not to.

Computers can be made to represent vagueness rather precisely.

> You should be able to represent in your data model, date-time library etc. vague dates and relative dates.

If it is needed. Often it is not needed. Or rather for most applications there is an implicit hard coded resolution, or error interval.

The library case is special and then why not just have an additional byte specifying the confidence interval. You only need a small enumerated type of 20 distinct values to encode confidence intervals from a nanosecond up to a millennium. Heck you can do it with bits if you want to.

Re: Some Notes About Time

#80

Post by masklinn »

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.

> Are you suggesting that every programmer should know about relativistic effects of time dilation in controlled scientific experiments?

No, he's declaring that not every programmer can afford to ignore these.

Post reply on HN