[Historic] The "time" of time

[Sean Gillies]

Aaron, have you ever seen the Common Eras project?

  http://commoneras.ecs.soton.ac.uk/category/Doctor%20Who.html

Leif might be lurking on this list for all I know. He and I have been
talking with a few other programmers in the
classics/byzantine/medievalist fields about expanding on this concept
to make something might suit us better than existing controlled
vocabularies. It gets interesting where otherwise solid chronologies
start to float loose from known dates (Ancient Egyptian Kingdoms, for
example) or where researchers dispute the beginnings and endings of
cultural periods.

On Sat, Aug 25, 2012 at 7:03 PM, Aaron Straup Cope
<aaronofmontreal at gmail.com> wrote:
> 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
>>
>>
>
>
> _______________________________________________
> Historic mailing list
> Historic at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/historic



-- 
Sean Gillies