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

111–118 of 118 posts

Re: Some Notes About Time

#111

Post by dfischer »

defrost wrote: post #13
martinced wrote: post #6

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). No leap seconds issues. No 25 hours-day issues. No 23 hours-day issues. No 59 seconds minutes issues. No 61 seconds minutes issues. And all it takes to store a time like that is a 64-bit integer and it is very convenient. And a lot of softwa…

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

Hi,

I find your opinion and experience on this matter very interesting. Could you possibly describe your experience or projects you've worked on that could shed some insight on the complicated issues time causes?

Re: Some Notes About Time

#112

Post by RyanZAG »

jtheory wrote: post #102
ianburrell wrote: post #95

Earlier quoted context omitted.

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 so…

24 hours from now is no problem if you're using unix time. Just add 24 hours worth of seconds -- when you convert back to the user's time, your conversion logic will take care of timezones. This is also incredibly important if serving an app over the internet as your user may have just flown from USA to Japan. Storing unix time solves this in the easiest way.

Same for working out how many days remain - you convert March 1st to a unix date, get an interval in seconds, and then convert that into a human readable format on display.

This isn't some revelation - unix time has been used successfully for decades now.

EDIT: Also, Postgresql uses a number very similar to unix time in the actual storage of the date - it just handles the pretty display for you. So you're arguing for using the same thing whether you say use a postgre datetime or a unix date number.

Re: Some Notes About Time

#113

Post by igravious »

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…

> Humans represent time vaguely rather than precisely. Computers tend not to.

Hi. A colleague of mine is working on a large medieval dataset than contains many dates and recently explained this concept of vagueness to me. What's the standard way for dealing with this in MySQL for instance, how do comparisons and orderings work for a collection of vague dates?

You're saying ISO 8601 can do this, and MySQL can talk ISO 8601?

Re: Some Notes About Time

#114

Post by nonamegiven »

chris_wot wrote: post #109
nonamegiven wrote: post #76

Earlier quoted context omitted.

Unfortunately Google can only think of that too.

I was attempting to generate discussion. Your snark is not welcome.

No snark intendend whatsoever. I was trying to figure out what the guy was talking about, and when I searched TBV the results were overwhelmed with Time Value of Money. I was observing that if the guy meant anything other than that, it would be all but impossible for someone to figure out if someone was not familiar with ... whatever he's talking about.

Re: Some Notes About Time

#115

Post by gpvos »

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…

Would that be 12 January Old Style or New Style? (And are you sure the year number changed on 1 January in the region where that text was written or published?) http://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates

Re: Some Notes About Time

#116

Post by chris_wot »

nonamegiven wrote: post #114
chris_wot wrote: post #109

Earlier quoted context omitted.

I was attempting to generate discussion. Your snark is not welcome.

No snark intendend whatsoever. I was trying to figure out what the guy was talking about, and when I searched TBV the results were overwhelmed with Time Value of Money. I was observing that if the guy meant anything other than that, it would be all but impossible for someone to figure out if someone was not familiar with ... whatever he's talking about.

In that case, I owe you apology :(

Love to know what this TVM is.

Re: Some Notes About Time

#117

Post by jtheory »

RyanZAG wrote: post #112
jtheory wrote: post #102

Earlier quoted context omitted.

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 so…

24 hours from now is no problem if you're using unix time. Just add 24 hours worth of seconds -- when you convert back to the user's time, your conversion logic will take care of timezones. This is also incredibly important if serving an app over the internet as your user may have just flown from USA to Japan. Storing unix time solves this in the easiest way. Same for working out how many days remain - you convert Ma…

> [Postgres] just handles the pretty display for you

It's rather more than that, though I don't have the time to kill digging into it now.

And personally I mostly seem to end up doing more complicated date processing in code, not queries; but there everything needs to be a date immediately (not unix time or similar) for most purposes -- then I can use complicated libraries written by others to let me do "simple" things with dates, like rolling months.

Ah, also: > you convert March 1st to a unix date Then that's where the complicated logic goes. Basically, you need that somewhere, and it's non-trivial (leap year calc is the least of it).

My point isn't that unix dates aren't useful for storage, but that they aren't useful by themselves for calculation.

Re: Some Notes About Time

#118

Post by tommorris »

igravious wrote: post #113
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…

> Humans represent time vaguely rather than precisely. Computers tend not to. Hi. A colleague of mine is working on a large medieval dataset than contains many dates and recently explained this concept of vagueness to me. What's the standard way for dealing with this in MySQL for instance, how do comparisons and orderings work for a collection of vague dates? You're saying ISO 8601 can do this, and MySQL can talk ISO…

I don't know much about MySQL, sorry. Mostly I use Postgres. I'd suggest the only really good way of solving is either something like tstzrange or daterange in Postgres. Or defining your own datatype, which most databases don't support.
Post reply on HN