[Historic] The "time" of time

[Aaron Straup Cope]

Ah, interesting. I didn't realize that ISO 8601 supported BCE.

Also, if it wasn't clear: I meant that you'd (almost) always end up with 
both a start date and an end date. This is fairly common for museums.

It's just that we get to try and teach computers to make sense of random 
human-strings at both end of the range. Random stuff like:

"c. 12th century to late industrial revolution"

Which is super interesting because there are in fact three date ranges 
happening here.

So as much as anything we need to find a way for museum folks 
(institutions) to define canned ranges for "c. 12th century" – because 
remember the granularity has capital-M meaning in many cases – as it is 
to denote the possible span of two ranges.

This ends up meaning you store a bunch more fields potentially but, 
modulo the part where it's all still hand-waving, if we can boil it all 
down to (signed) numbers then there's a portability to the data that 
isn't bound to any given database implementation (for date math).


On 8/25/12 6:08 PM, Dan Vanderkam wrote:
> 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
>