Time

Some time ago (ha ha ha) - I was thinking about time and how to properly reference it
in the situation where you have a time line of events that do not share either a specificity of WHEN the event happened, nor HOW LONG the event took place.    Why?   Because time lines all suffer from this problem (esp. in a database environment): typically you store a time stamp at some pre-considered resolution (day or minute or second) where the actual set of time line events might not work with that resolution (e.g., "Summer 1864").

Basically you need three things:

    1) A base timestamp
    2) A sense of the fuzziness of that timestamp – it's "granularity"
    3) A sense of the duration of the event – also granular

Done this way, the three things have the following properties:

1)  The base time stamp

It's set at the precision of the database holding it.
Depending on the granularity, you can zero out everything "too fine to be known".
What I mean by that is that the convention can be:

     a) Sep. 11, 2001 9:34 AM --->   2001-Sep-11 09:34:00
     b) Sep. 11, 2001 9:34:21 AM ---> 2001-Sep-11 09:34:21
     c) Sep. 11, 2001 09:34:21.84743 --- might need the 0.84743 to be in a separate field
            unless time stamps in the DB support fractional seconds.   If you didn't use MySQL's
            TIMESTAMP and instead did a FLOAT based upon some root epoch, then you'd have
            SOMEWHAT arbitrary precision (which is how the iPhone does it - kinda)
    d) Sep. 11, 2001  about 9 AM ---> 2001-Sep-11 09:00:00
    e) Early Sep. 2001 ---> 2001-Sep-01 00:00:00 (or another date if you can make a better "guess")
    f) 1943 ---> 1943-Jan-01 00:00:00

And so on.    Yes, that means that something that ACTUALLY happened in July of 1943, but listed
as just 1943 get plunked in January... but if we KNOW that's it's July we can shift it to 1943-07-01
because our "fuzziness" has decreased...

It can be an OFFSET from another time.   So, anything that's like "10 minutes AFTER..." would be
whatever the time of the other event "plus" 10 minutes with the understanding that the
resultant fuzziness is the WORSE of the two.    "5/16/2011 5:16:32 PM plus '10 miniutes'
becomes 5/16/2011 5:26 PM"

-----

2) The granularity says "how far along the base time stamp should I read it"?
In other words, "I know that the DB needs a point of time, but I realize that the
timestamp might not be that precise..."

     This can be established with a enumerated listing (not a set!), e.g.:
            sub-second
            second
            minute
            hour
            ...
            month
            year
            decade
            century
            ...
            eon

        or, even something numeric  (1000 days) I suppose.

    So the previous examples have the following fuzziness JUST based on the way they're presented...
            a) minute
            b) second
            c) sub-second
            d) hour
            e) day?  week?   month? - needs more context

3) Finally, there's the duration  - this is a "delta" time stamp that ALSO has a granularity

      It's measured from the base time explicit, implicit, or calculated.

        It can be ZERO or NULL – meaning that it's not relevant, or perhaps not really known.   If you think
        about it NO "real" event has zero duration, so it's OK to use that to represent narratives
        that don't explicitly refer to any duration of the event.  However, as you'll see, one can
        frequently be inferred from the narrative...

        So if:

            a) the base time is when the tower fell, it COULD have a duration giving the sense
                of how long it took to fall;
            b) could be zero which we'd take to mean 'that's when the perspective started/happened'
            c) COULD BE NEGATIVE – which we'd take to mean "this describes things leading UP TO the event"
                    (I don't expect we'd use this but it's an intriguing concept for dealing with cause/effect perspectives!)

    Think of it as a way to relate things "WHILE" something happened.


So if you tag perspectives this way, you can relate them on a common time line that's as fuzzy as it
needs to be, AND as fuzzy as it has to be because of the reality of the narrative.   This makes sense
because that's how relate to time in narratives ALL THE TIME!    So, it's a 3-tuple (when, fuzziness, duration).

Examples:

"Last week, I went shopping, and..."   (you have a sense of an offset from "now" BACK a few days, but
    not quite sure WHICH day   = (Now minus a week, days, null or something depending on the rest of the narrative)

"This picture of my grandmother is from around 1914..."  (1914, years, irrelevant?  depends on the narrative, I suppose)

"Ten minutes after the tower fell, there was an explosion..."   (2001-09-11 18:34:42 + ~10 minutes = 2001-09-11-18:44:00, minutes, minutes)

"In the 1950's the culture..."  (1950, decade, 10 years)

"In the Paleozoic era..." (Now minus 542 million years, eon, 291 million years)...

As you can see, it covers almost everything.

As a concept you could also have a "NULL base" that could be used to describe things on a time line that
do not necessarily require a specific time to happen, e.g.:

"At 13 weeks of development, the fetus..."   (None + 13 weeks, days, days?)
(which technically makes the first elements a 2-tuple of it's own...)...