-
Notifications
You must be signed in to change notification settings - Fork 2
Home
As the Abstract Conceptual Model for Time OGC23-049 has passed the OGC Technical Committee vote for publication, much of the content below is now unnecessary and will be removed.
-
We are also experimenting with using an OGC Slack channel #temporal-DWG
-
Existing standards:
-
Restrictive profiles of existing standards:
IETF RFC3339 Date and Time on the Internet: Timestamps is a useful restriction of ISO8601;
W3C Data and Time Format is another restriction of ISO8601.
-
Other useful Documents
-
Stakeholders in temporal infrastructure:
ISO established an Ad Hoc group on Time and published a Temporal Vocabulary ISO34000. There is also an approved ISO project to develop tags to indicate a variety of widely used calendars; ) [OGC Naming Authority](https://www.ogc.org/about-ogc/policies/ogcna/ has a machinable register of some temporal Coordinate Reference Systems;
BIPM is responsible for coordinating atomic time across the globe and maintaining a civil Universal Coordinated Time (UTC) which is the basis for the Gregorian Calendar. It also defines the fundamental constants, such as the second, kilogramme and metre; ) IERS is responsible for tracking Earth's rotation with respect to the stars and the Sun, and declares when leap seconds should be introduced into UTC so that the Gregorian Calendar maintains consistency with the Earth's rotation with respect to the Sun, to a precision of better than one second. This portantial discrepancy is because the second is now defined by atomic clocks rather than a fraction of the rotation period of the Earth.
MISB Moving Imagery Standards Board Processing of moving imagery often needs high precision coordinated time and Chapter 6 in this document defines good or best practice.
IETF has several RFCs that are about time, such as the RFC3339 above, the NTP Network Time Protocol](https://www.rfc-editor.org/rfc/rfc5905.html) and the recently proposed TZif Time Zone Information Format.
-
Examples of good and bad practice: See MISB Motion Imagery Handbook, Chapter 6.
-
Examples or catalogue of temporal systems: See Wikipedia List of Calendars and Current Time Standards
-
Draft text
Quid est ergo tempus?
Si nemo ex me quaerat, scio.
Si quaerenti explicare velim, nescio.
Saint Augustine, Confessions, XI
What then is time?
If no one asks me, I know.
If I wish to explain to him who asks, I do not know.
This conceptual model proposes four regimes
:
- Event Regime - No clocks, logic only
- Clock Regime - Clocks, ticks, integer arithmetic only, no –ve times
- Coordinate Regime - CRSs, number line to interpolate between ticks, real arithmetic, extrapolate before zero/datum/epoch
- Calendar Regime - Calendars, abnormal arithmetic, earth sun and moon rotations, months, weeks
Set of EVENTS ordered in time (ta, tb, tc, … tn), that may be: Finite or Countably infinite (like the integers)
No clocks
Simple Logic Operators defined to determine if 2 times are: The same, or one earlier, the other later (maybe an earliest and latest times?)
2 times define Relation(ta,tb), ta<tb, but NOT duration (tb-ta)
Any 3 or 4 events could allow logic (Allen 1983) such as:
tb is in (ta,tc), ta<tb<tc
(ta,tc) overlaps (tb,td), ta<tb<tc<td,
(ta,td) contains (tb,tc ), ta<tb<tc<td,
(ta,tb) disjoint from (tc,td), ta<tb<tc<td,
No other times exist or can be interpolated
Similar to RCC8 spatial operators
Not sure about continuum. Probably OK. Operations are the distinguishing features.
Examples: Geology, Archaeology, Ice and sediment cores, King Lists and Genealogies
Could be multiple sets, each with own ordering, may or may not be relations between events across sets
ISO8601 notation 2014-10-07T10:00 is a BAD notation for this regime. Notation should just be labels E.g. “Jurassic”, “65My ago”, “Reign of Tiglathpileser III”, "1.562m from top of core" (?? not sure about ice cores? Tree rings are definitely Regime 2, clocks)
“Clock” defined as any regularly repeating physical event that can be counted (or perhaps measured?)
Countably infinite set of ordered time INSTANTS.
Fixed precision, determined by interval between instants
No intermediate times can be calculated between ticks
Similar set of operations: Same, Earlier/later, Operations for Instants and Intervals
tb is in (ta,tc), ta<tb<tc
(ta,tc) overlaps (tb,td), ta<tb<tc<td,
(ta,td) contains (tb,tc), ta<tb<tc<td,
(ta,tb) disjoint from (tc,td), ta<tb<tc<td,
Can now calculate duration (tb-ta) as metric defined
Could be an earliest or latest, or an epoch (datum time)
Examples:
- TAI International Atomic Time, which cannot be used to time events to femtosecond precision, or cannot be used to time events prior to Epoch!
- Pendulum swings
- Heart-beat
- Vibration of a piezo-electric crystal
- Rotation of earth around sun
Notation implying higher accuracy than ticks not appropriate. E.g. Julian days labelled 2014-10-07T10:00:00.0+01:00
Precision defined with countably infinite set of ‘ticks’
Assume normal mathematical interpolation between ticks
Epoch defined, perhaps with practical earliest/latest times
Assume mathematical extrapolation before epoch or into the future: +/-
Logical Operations and calculations well defined
Other ‘UoM’ can be defined but must be totally ‘regular’ E.g: 1 hour = 60 mins, 1 day=24 hours, 1 year = 360 days E.g: milliseconds, kiloseconds
Examples: Unix milliseconds, Julian Days, Julian Years, etc
Epoch may be ill-defined (start of reign of Ashburnipal III) so CRS is relative, not absolute – see Regime 0.
Epoch should be defined in terms of TAI, UTC, etc
Regimes 1 & 2 blend
Think carefully about timestamp notation, such as ISO8601:
2014-10-07T11:00:00.0
actually implies LOCAL time, which could be solar!
2014-10-07T10:00:00.0Z
implies UTC, and therefore leap seconds
Astronomers epoch is usually at midday, everyone else prefers midnight, of specified day
Anything requiring an algorithm beyond normal arithmetic
E.g: Years CE and BCE (AD & BC). There is no year 0BCE or 0CE, so ‘normal arithmetic’ gives unexpected results E.g. UTC Gregorian, Mayan, Jewish, etc
Should have an Epoch
May have earliest and latest defined times, or times when algorithm invalid
Usually approximates a CRS to astronomical events
Algorithmic rather than observed calendar
A CRS is not a Calendar, a Calendar is not a CRS!
ISO 8601:2004: 2014-10-07T10:20:00.0
Is 0000-01-01T00:00:00.0 valid?
2013-07-01T00:00:00 minus 2013-06-30T23:59:00 = ?
59 or 60 or 61 seconds?
2012-07-01T00:00:00Z minus 2012-06-30T23:59:00Z = ?
59 or 60 or 61 seconds?
Do not assume notation implies arithmetic, CRS or calendar!
What notation applicable for each regime?
Answers: 2012-07-01T00:00:00 minus 2012-06-30T23:59:00 = 60 possibly, if local time is UTC
2012-07-01T00:00:00Z minus 2012-06-30T23:59:00Z = 61 precisely because ‘Z’ implies UTC, and leap seconds only introduced at "midnight" UTC
Astronomical times, local solar time, sidereal time, relativistic, helio-spatial, accountancy, etc Requires observation of moon, sun or stars
Could be several regimes:
Observation based calendars
Sidereal time
Local Solar time, Mean Tropical Year
Space weather time on Sun
Relativistic
Etc
Plenty of realistic detailed use cases
Accountancy? Weeks and months!
Plenty of calendars in this regime
All defined timescales and calendars, as they are based on physical devices, have a temporal scope; That is, a time interval for which they are valid. Outside of the this interval, people may still choose to use that temporal reference system, but with indeterminate accuracy and precision, and no method of determining them.
Simple Temporal CRS form for registration
Clearly specified and determined datum (epoch)
May be absolute (E.g. specified in UTC or TAI)
Or relative (start of ice core, start of Tiglathpileser III’s reign)
Well defined and named unit of duration
Well defined directions (+ and -)
Normal arithmetic
No missing or extra years, seconds, etc
There is a value of zero at the datum
There may be ‘earliest’ or ‘latest’ practical values
Sensible CRS name
Passes OGC-NA criteria
URI scheme
Has convincing use case to be separate from existing CRSs
http://www.opengis.net/def/crs/OGC/0/AnsiDate
http://www.opengis.net/def/crs/OGC/0/ChronometricGeologicTime
http://www.opengis.net/def/crs/OGC/0/JulianDate
http://www.opengis.net/def/crs/OGC/0/TruncatedJulianDate
http://www.opengis.net/def/crs/OGC/0/UnixTime
http://www.opengis.net/def/axis/OGC/0/days
http://www.opengis.net/def/axis/OGC/0/mya
http://www.opengis.net/def/axis/OGC/0/seconds
http://www.opengis.net/def/datum/OGC/0/AnsiDateDatum - days elapsed from 24-Nov-4714 BC (12h00 UTC), proleptic Gregorian calendar
http://www.opengis.net/def/datum/OGC/0/JulianDateDatum
http://www.opengis.net/def/datum/OGC/0/TruncatedJulianDateDatum
http://www.opengis.net/def/datum/OGC/0/UnixTimeDatum
http://www.opengis.net/def/datum/OGC/0/YearZeroDatum