What is the best way of storing time?

Question

What is the best way to store time ?

There seem to be a lot of ways to handle this.

Wikipedia has a listing, but most of them are epoch based. What if you were an archaeologist and wanted to store a date in your program?

Answer 1

How exact do you think archaeological dates are? Archaeologists would just store the year (at best). Just make sure you allow more than two digits for the year.

Seriously, it doesn't matter a whole lot. IIRC, the Unix epoch won't run out of milliseconds for another 30 years. On one hand, I want to think that some of my programs will still be useful then. On the other, it will certainly be someone else's problem.

Answer 2

Number of picoseconds since the big bang? 64 bits should be enough, although we would have to watch out for the Y130B bug.

Answer 3

Use a negative number.

A 64bit long of milliseconds is +/- 292 million years, which is enough for anyone except an astronomer or geologist.

A long of seconds is significantly more than the age of the universe.

Also note, as others have pointed out, that in case of archeology you have problems with timestamps anyway, because the dates are all uncertain.

For example in Egyptology, there are periods where the sequential chronology is known, but nobody is quite sure how that translates into our year count, even though it's narrowed down to a few possibilities. So you end up with dates listed as "X, Y, or Z BCE", and something else known to have happened 5 years later as "(X+5), (Y+5) or (Z+5) BCE". Of course when talking among themselves, the Egyptologists will call the dates "so many years after blah", where blah is an important event, rather than trying to relate it to our calendar at all.

To cope with that, you'd want to copy them, and use an epoch based on the best available event for the period you're studying.

Answer 4

Archaeologists, depending on their field, typically want to store dates as years B.P. - that is, Years Before Present. The further you go away from the present, the more "fuzzy" dates become and the less absolute precision matters. So for archaeologists, I would just store integers representing YBP.

If you're talking about archeologists that study post-columbian timeframes (rather specialist, but they do exist), then you should probably use a time standard that includes at least dates as well as years. The java spec uses a 64 bit counter of milliseconds before or after the Unix epoch, and that works pretty well, since it has millisecond precision and a very wide range.

Answer 5

Jim Croce had time in a bottle.

Answer 6

Many older systems used Julian dates. Works well.

Answer 7

You should follow the recommendations in the relevant RFC .

Answer 8

Standard date representations should be just fine when combined with a measure of error in the date (e.g. 100 BC +/- 100years). You can't use YBP because the present is constantly moving forwards.

Answer 9

I'm on the Java JSR-310 (Date Time API) and we've defined time using nano second accuracy, since standard epochs (i.e. "January 1, 1970 at midnight UTC")

If you want to see the debate which led up to this and the pros and cons from folks far more knowlegable than me, search back through the public dev group emails.

Answer 10

Any date/time system needs a reference. You have to define a null point somewhere. A sepcific date is represented as an offset to it. I can not think of a system that works differently.

You can try something similar to the kelvin scale in temperature: 0 K is the lowest possible temperature, therefore all temperatures most be >= 0. In this case, it would be the moment the fourth dimension (time) came into existence. Good luck defining it ;-)

Another thought: The bigger the distance to now() becomes, the less important is the precision. (If you read anywhere that Socrates died 399 BC, do not take this too literally...) So a float would be a better type than an integer.

Answer 11

One common design problem you see in databases is that people get tricky with date and time storage in the hopes of optimising performance. There is very rarely any good reason to stray from using the system supplied data types for dates, however, and plenty of pitfalls if you do stray.

Answer 12

Read Calendrical Calculations.

Epochs work. In the US and Europe we generally use the Gregorian Calendar. It was adopted at various dates in various countries. It was initially pitched in 1582. But some countries (the US) didn't adopt it until 1752. Except in Alaska, where it was 1867.

All dates prior to adoption (in your country) are called "proleptic" dates. They're dates with caveats; some interpretation is required to understand them.

However, this all works great. If you're doing archeological work after the adoption of the Gregorian Calendar, the epoch doesn't matter. If you're doing work before the calendar, but after proleptic year "1" (remember, there was no Gregorian year before 1582,), then a epoch of Gregorian year "1" (like in Calendrical Calculations) is no worse than any other.

If you're doing work before proleptic year 1 (years -1 through -2.0b) you'll still be in good shape with a simple epoch-based system. You'll have to-the-day accuracy for things that happened (a) before humans counted the days and (b) when the length of the day was different than it is now. For proleptic years prior to -2.0b, you'll have to invent your own calendar. Or use approximations.

In short, what's wrong with an epoch? Do you have something better? Do you mind sharing?