[Historic] The "time" of time

[Aaron Straup Cope]

(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,