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

81–90 of 118 posts

Re: Some Notes About Time

#81

Post by nonamegiven »

At a more coarse-grained level, "Calendrical Calculations" by Dershowitz and Reingold is very interesting. It describes many different world and historical calendar systems, and includes lisp code to convert between them.

Among many other problems, converting between calendar systems requires that you define when a day starts; there are many ways to define that among the systems.

I think I have the latest, the third edition, https://en.wikipedia.org/wiki/Special:BookSources/9780521885...

Re: Some Notes About Time

#82

Post by icegreentea »

rimantas wrote: post #77
Dylan16807 wrote: post #66

Earlier quoted context omitted.

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.

Well, the choice of GMT certainly made picking the international date line earlier. Certainly useful that 180 degrees around the world is mostly water.

Re: Some Notes About Time

#83

Post by albertzeyer »

sla29970 wrote: post #52
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…

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…

Well, there is libtai from djb. Isn't that credible?

Re: Some Notes About Time

#84

Post by tommorris »

rmc wrote: post #67
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…

Eventually, we'll have an even better way of representing date-times that are more like bitmasks. We can then represent in a sane way the concept of opening hours. If you say the shop is open from 9am to 4:30pm Monday to Saturday, how do you do that? For the record, the Open Street Map project has come up with a human readable way to encode opening hours. http://wiki.openstreetmap.org/wiki/Key:opening_hours

Yup, and they've properly specced it out and everything. I frequently advocate people nick this and reuse or build on it.

Re: Some Notes About Time

#85

Post by tommorris »

rdtsc wrote: post #79
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 th…

I'm not saying you can't do it. I'm saying that a lot of the software one writes against (date-time libraries, databases, data formats etc.) don't make it easy. And programmers don't think about it very hard.

Re: Some Notes About Time

#86

Post by tommorris »

rolux wrote: post #64
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…

> If I am digitising an old text of unknown origin, and on a page it says "January 12", and on the page after that it says "January 15", can I represent those with a reference to an implicit but unknown year? I don't know the year, but I do know that the January 12 instance comes before the January 15 instance on the next page. And at some future point, we might deduce from circumstantial evidence what year it was an…

You may be able to infer it from the sequential ordering of events described in the letters, but, yes, point taken.

Re: Some Notes About Time

#87

Post by mgunes »

nonamegiven wrote: post #81

At a more coarse-grained level, "Calendrical Calculations" by Dershowitz and Reingold is very interesting. It describes many different world and historical calendar systems, and includes lisp code to convert between them. Among many other problems, converting between calendar systems requires that you define when a day starts; there are many ways to define that among the systems. I think I have the latest, the third…

For those less practically interested in the history of the computation of time, Arno Borst's "The Ordering Of Time: From The Ancient Computus To The Modern Computer" is recommended reading.

Re: Some Notes About Time

#88

Post by taeric »

rmc wrote: post #72
taeric wrote: post #45

Earlier quoted context omitted.

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.

I, of course, can not disagree. Just wanted to add to the voices that point out much in dealing with time in computers depends on your goal.

Re: Some Notes About Time

#89

Post by icambron »

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…

I would go so far as to say that time zones are rarely presentation-level issues. Want to have a meeting every Tuesday at 2:00 New York time? Better make sure you know the New York part or daylight savings will break it. Want to wake up every day at 9:00? If you don't track the zone that preference is set in, you won't get that right when you travel. Time zone isn't a presentation-only thing because people's behavior depends on their time zone.

Re: Some Notes About Time

#90

Post by sla29970 »

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?

Read between the lines of http://www.bipm.org/cc/CCTF/Allowed/18/CCTF_09-27_note_on_UT... about what systems of time distribution already exist and which of those are approved for use by national and international agencies.
Post reply on HN