5 ms·

Time is even more complicated than that because of vagueness, either intentional or unintentional. Humans represent time vaguely rather than precisely. Compute

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 it after I moaned on Twitter.) You should be able to represent in your data model, date-time library etc. vague dates and relative dates. When I say someone was born in 1941, I don't mean they are born at 1941-01-01T00:00:00Z. When I say that something happened on Thursday, I don't mean it happened at 2013-01-17T17:04:00Z. It may have happened at any time on Thursday. If you store everything as Unix epoch seconds, good luck representing vagueness. ISO 8601 gets around the problem rather neatly by being big-endian and allowing omission at any point. Wanna say 1941? "1941". Want to say January 1941? "1941-01". Want to say January 14, 1941? "1941-01-14". Want to get very detailed? You can add points of a second: "1941-01-14T12:14:03.0482Z". You can do timezones. 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? 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 and the sequential ordering will still make sense. Relative dates would be useful here. ISO 8601 allows you to represent ordinal dates (the number of days since the beginning of the calendar year). Can your date-time representation deal with moveable feasts like Easter? Have a look at the WHAT WG Wiki page on Time to see more obscure use cases: http://wiki.whatwg.org/wiki/Time http://wiki.whatwg.org/wiki/Time Your date-time representation, storage format and calculation libraries are probably inadequate.

mbq 14y ago
The author only advices to use UNIX time to precisely measure time intervals and store precise timestamps; your points are of course valid, but they are not a reason to degrade precise data into human-readable pandemonium.
- tommorris 14y ago
  Ah, my mistake. I'll rephrase my original comment.
rolux 14y ago
> 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 and the sequential ordering will still make sense. Relative dates would be useful here. Of course, if the year is unknown, and could be before ~1918, and your dates are, say, the dates of two letters, you can't even be certain about the ordering of "January 12" and "January 15".
- tommorris 14y ago
  You may be able to infer it from the sequential ordering of events described in the letters, but, yes, point taken.
rmc 14y ago
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 http://wiki.openstreetmap.org/wiki/Key:opening_hours
- tommorris 14y ago
  Yup, and they've properly specced it out and everything. I frequently advocate people nick this and reuse or build on it.
rdtsc 14y ago
> 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.
- tommorris 14y ago
  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.
tekromancr 14y ago
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.
igravious 14y ago
> 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?
- tommorris 14y ago
  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.
gpvos 14y ago
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 http://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates

mbq 14y ago

The author only advices to use UNIX time to precisely measure time intervals and store precise timestamps; your points are of course valid, but they are not a reason to degrade precise data into human-readable pandemonium.

tommorris 14y ago
Ah, my mistake. I'll rephrase my original comment.

rolux 14y ago

> 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 and the sequential ordering will still make sense. Relative dates would be useful here. Of course, if the year is unknown, and could be before ~1918, and your dates are, say, the dates of two letters, you can't even be certain about the ordering of "January 12" and "January 15".

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

rmc 14y ago

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 http://wiki.openstreetmap.org/wiki/Key:opening_hours

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

rdtsc 14y ago

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

tommorris 14y ago
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.

tekromancr 14y ago

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.

igravious 14y ago

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

tommorris 14y ago
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.

gpvos 14y ago

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 http://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates