[Historic] The "time" of time

[Sean Gillies]

On Thu, Aug 30, 2012 at 5:12 AM, Aaron Straup Cope
<aaronofmontreal at gmail.com> wrote:
> (Comments inline.)
>
>
> On 8/29/12 9:04 PM, Brad Thompson wrote:
>
>> On the 'time of time' topic: I think ISO 8601 is a suitable standard to
>> use as a basis (it allows a standard for describing durations, allows
>> very granular time intervals, etc), but that two modifications would be
>> necessary to make it useful within a historical mapping platform:
>
>
> I for one love the idea of forcing the name "time pixels" on the rest of the
> world!
>
>
>> 1) Degree of confidence (as discussed already on this thread), to allow
>> quantification of what 'circa' means for a particular item. One simple
>> (too simple?) method might be to store two values for each Start and End
>> field: the timestamp value and a confidence value, both  stored using
>> ISO 8601 markup. The 8601 standard allows durations to be described
>> independent of a date, so the confidence value, like a temporal pixel (a
>> tempel?) would refer to an amount of time. In other words, a small value
>> would indicate high confidence and a large value would indicate lower
>> confidence. For example, the entry for the Challenger explosion would
>> have very small tempels for both Start and End timestamps, possibly as
>> small as a few milliseconds, whereas the entry for Stonehenge would have
>> a Start timestamp with a large tempel, measured perhaps in a few hundred
>> years. Aaron, how would something like that line up with what you
>> discussed?
>
>
> Yeah, one way to think about those confidences would be that they are the
> default set of granulaties that can be calculated with a high degree of
> reliability by code alone (which probably means lib_pcre).
>
> For example the buffer zone around plain old "2012" probably shouldn't
> include "2011-12-31". Likewise for "2012-12" and so on down the list.
>
>
>> 2) Correlation between the ISO 8601 standard (aka today's Gregorian
>> basis) with other calendar systems. Throughout history, great variations
>> in calendaring systems, sometimes with highly localized discrepancies,
>> have existed. A useful historical platform would be flexible enough to
>> indicate these, and to translate between systems in the same way that
>> place labels can be localized by language. One crazy example from the
>> Julian-Gregorian switchover is Sweden, which chose to adopt the
>> Gregorian calendar over a period of 40 years, by skipping all leap years
>> between 1700 and 1740. But by accident, they observed leap years anyway
>> in 1704 and 1708, then decided in 1712 to revert back to the Julian
>> calendar, and added days in February to make up the discrepancy. In
>> roadmapping Pastmapper, I've used this example to demonstrate the need
>> for all of the entries called 'Sweden' during these years to be
>> associated with the appropriate calendar variants, so that February 30,
>> 1712 can be shown to have existed in Sweden but not in Norway. This
>> would be manifested in Pastmapper by presenting a user viewing a map of
>> this era and region with a time slider for the 'expected' Gregorian
>> calendar (ISO 8061) and an optional one using the Observed Local calendar.
>
>
> I like the distinction between ISO-8601 and "observed".
>
> Given the squirrel-y ness of calculating an "observed" date and the extended
> dependency tree of requirements (geo data, lib_timepixel for doing fast
> math, etc.) I could imagine trying to tackle the whole thing quickly being
> daunting and a bit depressing.
>
> If we treated ISO-8601 as a kind of spherical mercator of time (sorry) then
> we have the advantage of "just working" with the computers post Epoch, a way
> to perform simple date math without the costs of
> why-hasnt-lib-timepixel-been-ported-osx-mountain-man and a simple enough
> rule set of how those dates work to start tackling "observed" dates on a
> case-by-case basis.
>
> I don't know if it's useful for the larger conversation but I recently
> posted "whereonearth-timezone" to Github:
>
> https://github.com/straup/whereonearth-timezone
>
> It is a linear snapshot of the WOE timezones smushed up with Eric Muller's
> TZ polygons. To the extent that these are a) rooted in geography and b)
> change over time c) don't change all that often maybe they are a useful
> dataset for poking at issues around "observed" dates?
>
> Cheers,

Time pixels is a fun concept. I wonder if time could also be treated
using familiar elements of OSM's data model: moments as temporal
"nodes" (datetime + precision/confidence) and periods as temporal
"ways" (ordered list of moments)? I'm often looking for symmetry in
things and this is perhaps overdoing it, but it does build on a proven
model. And snapping physical nodes and ways to the ends of temporal
ways might pave the way for exploring the transition of features over
time.

-- 
Sean Gillies