[Historic] The "time" of time

Dan Vanderkam danvdk at gmail.com
Sat Aug 25 23:08:03 BST 2012


It looks like ISO-8601 does support BCE: you'd encode the date as
something like "-0002-12-25".
http://en.wikipedia.org/wiki/ISO_8601#Years

There are also some interesting questions here about whether you use
the Gregorian calendar before the was a Gregorian calendar, or the
Julian calendar before there was a Julian calendar. ISO-8601 uses the
"proleptic Gregorian" calendar, and that seems like a reasonable
choice.

An alternative to storing (timestamp, granularity) would be to store
an (earliest possible timestamp, latest possible timestamp) pair. I
used this format in OldSF and found it quite handy. There were many
photos which had only a year, or a range of years, or just a decade.
The pair of timestamps lets you encode this precisely without worrying
too much about what the granularity field really means.

  - dan

On Sun, Aug 26, 2012 at 12:58 AM, Aaron Straup Cope
<aaronofmontreal at gmail.com> wrote:
> One of the things that a few of us in the museum world have been talking
> about is boiling any given date in to 4-5 individual fields:
>
> * A display date, like "c. 12c crazy times"
>
> * An ISO-8601 date string
>
> * A boolean indicating BCE
>
> * A granularity, which is little more than a label/pointer to a function
> that calculates a date range for a starting (ISO-8601 + is_bce).
>
> Flickr used "granularities" to express month, year, decade and eventually
> circa for photos in the Commons. Circa was simply decided from on high
> (read: me) to mean 5 years on either side of a date but you could make the
> rules governing date in and dates out as complex as you wanted. They just
> need to be documented somewhere.
>
> * A function for encoding/decoding one end of granulatity(iso8601, isbce) as
> a signed (big) int for storing the above as plain numbers for doing fast
> date ranges in a database. The idea is that 0 would continue to mean Jan 1
> 1970 and that anything before it would become a negative number.
>
> An added bonus would be something that could take (iso8601, bce,
> granularity) and pre-generate as good a display date as possible.
>
> It's still mostly talk although the talk has started to include words about
> grant money to find someone to do the encoding/decoding. The last thing I
> want to do (or can) is suffer that kind of date math.
>
> But it would be super useful across a range of fields, I think.
>
>
>
>
> On 8/24/12 12:28 PM, Jeff Meyer wrote:
>>
>> Mikel's spherical Mercator thread triggered another question for me - if
>> we were to add the concept of time to any map-/geo-related objects, how
>> would we express that time?
>>
>> Does anyone have a recommendation for this?
>>
>> ISO-8601 is often referenced (and maligned) as the relevant standard,
>> begging the questions:
>> - Which ISO-8601?
>> - How to handle BC / negative years?
>> - Why use such an odd convention (YYYY-MMM-DD... big Endian?)?
>>
>> I believe the OpenLayer guys have run into some interesting challenges
>> working with this format.
>>
>> - Jeff
>>
>> https://github.com/openlayers/openlayers/pull/413
>>
>> --
>> Jeff Meyer
>> Global World History Atlas
>> www.gwhat.org <http://www.gwhat.org>
>> jeff at gwhat.org <mailto:jeff at gwhat.org>
>> 206-676-2347
>>
>>
>>
>>
>> _______________________________________________
>> Historic mailing list
>> Historic at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/historic
>
>
>
> _______________________________________________
> Historic mailing list
> Historic at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/historic



More information about the Historic mailing list