currentDate / Time in Millisecondsmillis
Standard Specification
Persistence of Time

This document specifies a strategy to persist time, designed for 3rd party reference and compliance.
To achieve compliance, the following definition and conventions must be kept.

Persisted Time is a tuple formalized as:

Persisted Time = {Universal Time[, Timezone Offset[, DST]]}
Universal Time = {Numeric Timestamp[, Motion]}
  • Universal Time
    • mandatory
    • Numeric Timestamp
      • mandatory
      • the measured value of the UNIX timestamp in milliseconds or any time measurement unit more precise than milliseconds
    • Motion
      • optional
      • an implementation-dependent function which describes motion (variation of velocity in time) measured against a reference point in a relativistic context. Implementations can then calculate a corresponding timestamp at the reference point, if needed.
  • Timezone Offset
    • optional
    • relative to UTC, measured in minutes or any time measurement unit more precise than minutes
  • DST (Daylight Saving Time)
    • optional
    • a boolean value indicating whether the measured instant occurred during DST
Universal Time is sufficient to uniquely define an instant
Local Time is non-arbitrary & non-regional
Timezone Offset is flexible & valid beyond planetary surface

Basic Principles
The purpose of this specification is to maximize scalability, portability, server-database compatibility, independence of arbitrary concepts and the ability to interchange components.

It specifies persistence of time in connection with stochastic events, recurrent event definitions being out of scope.

Strategic outcomes include readiness for relativity, including orbital & deep-space flight.

1. Universal Time is sufficient to uniquely define an instant
1.1. Universal Time is sufficient to define unique instants. It represents the distance in time from the measured instance to a universal epoch. The epoch and distance of choice are the Unix Epoch and Unix timestamp.

1.2. Timezone Offset and DST are optional locality descriptors. They only need to be persisted to the extent that the server needs to reconstruct local time. Considering the many-to-one nature of client-server conversations, if locality descriptors are needed server-side, they must be explicit & provided by client or database; if they are needed on the client-side they are usually implicit given that frameworks / programming languages can convert universal time to local time on the client-side without additional information. Timezone Offset and DST are, thus, optional in persistence, depending on architectural design & implementation.

2. Local time is non-arbitrary & non-regional
2.1. Reconstruction of local times from persisted universal times is implementation-dependent & not mandatory, as described in p.1.2. However, if it occurs, reconstruction should be independent from arbitrary names or decisions such as the adherence of a country to a certain regional timezone. Timezones defined by a quantifiable offset rather than an arbitrary name or region are preferred to reconstruct locality. Therefore, the Timezone Offset will be persisted rather than a timezone name.

2.2. Geographical information (i.e. persistence of an entity's location) is not a subject for persistence of time and should be treated in a separate strategy.

3. Timezone Offset is flexible & valid beyond planetary surface
3.1. Timezone Offset is flexible beyond established national ranges. Though it can be observed that national & regional timezones (and implicitly their offsets) obey natural limits such as -24h < Timezone Offset < 24h, this specification imposes no conceptual restriction around offsets: -∞ < Timezone Offset < +∞

3.2. Maximum offset flexibility as defined by p.3.1 allows Timezone Offset to become a function of angular distance to the Greenwich meridian around the planetary axis. In 3 spatial dimensions the Greenwich meridian can be extended to a semiplane, thus angular distance can be measured for any object on orbit. Offset becomes irrelevant for non-orbital motion.

The following examples will use the extended tuple form for didactic reasons only. Also, universal time will be measured in milliseconds and timezone offset in minutes:
  • 2016-Aug-30 20:00:00 in Switzerland is persisted as {1472580000000, +120, true}
  • 2016-Dec-30 20:00:00 in Switzerland is persisted as {1483124400000, +60, false}
  • 2016-Aug-31 02:00:00 in Singapore is persisted as {1472580000000, +480, false}
  • 2016-Dec-31 03:00:00 in Singapore is persisted as {1483124400000, +480, false}
  • 1990-Apr-24 08:33:51 at the Kennedy Space Center is persisted as {640960431000, -240, true}

  • DST stands for Daylight Saving Time, i.e. summer time
  • Locality descriptors, in the context of the current document and unlike geographic coordinates, describe the local time measurement context (Timezone Offset and DST). While, at a first glance, they may seem to describe a spatial range of locations they do not; this is only a consequence of the widespread convention that countries choose timezones with proper offsets (depending on daylight). Note that this choice is arbitrary and often correlated with the distinction between timezone names and timezone offsets. Also note that timezones and timezone offsets are essentially an imperfect, primarily social & economic attempt to synchronize local time with local daylight. However, numeric timezone offsets are universally quantifiable, hence the advantage of persisting offsets.
  • implementation-dependent stands for a concept which is represented within this specification but has a structure that is highly dependent on architecture, design decisions and implementation.

Creative Commons License


version 1.00 -