WP3 Workshop 16/01/2002 Timestamps

Timestamps We would like the information system to associate each measurement with the time it was made We would like to handle fresh and archive data in a uniform manner All information must carry a timestamp

Timestamps – what? ASCII timestamp Binary timestamp Formatted string E.g 2002-01-16T12:45:50.36Z Binary timestamp Local binary representation Linux – two ints/longs

ASCII Format A number of efforts currently underway IETF currently has an RFC for defining date & time format for internet based on the standard representation of dates and times ISO8601 GGF also has a standard model, more or less same; But includes meta-info such as precision & accuracy information

ASCII Format IETF format (ISO 8601) GGF format (grd-perf-15-1) Yyyy-mm-ddThh:mm:ss.FfffZ T & Z (specifies UTC) are compulsory GGF format (grd-perf-15-1) As above but with the inclusion of accuracy resolution information Yyyy-mm-ddThh:mm:ss.FfffZxxxryya Number before ‘r’ is the resolution, ‘a’ is accuracy eg 2002-01-16T12:46:48.7567Z.00000001r.00001a

Binary Format New/Current Unix struct timeval is implemented using two long integers First is 64-bit signed second value Last is 64-bit signed micro-second Not enough precision for future applications with fractional part. Resolution can be different for platforms and programming languages

Timestamps How is time defined & referenced ? Based on the rotation of the earth on its axis – Universal Time (UT/UT0/UT1/UT2) TAI (Temps Atomique International ) (a.k.a Atomic time) S.I. Second defined as 9192631770 cycles of the caesium resonance UTC Time (Coordinated Universal Time) Same S.I. SECOND as TAI, but adjusted to include steps (leap seconds) to keep within .9s of UT1

Timestamps How is time referenced ? In relation to the time-definition’s epoch Each definition has a different epoch TAI 1-1-1958 UTC 1-1-1972 (sort of) GPS 1-1-1980

Timestamps – UT1,UTC & TAI But UTC = TAI – n x (1s) and UTC kept within 0.9s of UT1 (irregular) Integer leapseconds since 1972 TAI - UTC rebased to 10s IERS (Paris) determines when to introduce +/- leapsecond, very irregular Introduced as an extra second at end of a month (currently only June and December used)

Leapseconds -problem Problem converting between ASCII and binary (UTC) timestamps Must possess times at which leapsecond was introduced All sites/nodes must view the same information “A second is represented by an integer from 0 to 60; the values 60 and 61 occur only for leap seconds and even then only in Java implementations that actually track leap seconds correctly” – JDK documentation

Leapseconds, an example Normal (common) year = (365 x 86400) seconds 1998 lasted longer (due to aggregate deceleration of the earth due by tidal forces) A leapsecond was introduced by IERS 1-December-1998 23:59:58 1-December-1998 23:59:59 1-December-1998 23:59:60 (+1s) 1-December-1998 00:00:00

Problem- Timestamp Conversion b consumes information Ia(ta) a b Assume: sites a & c are corrected for leap seconds, b is not When b utilises Ia(ta) it must first convert to binary, this value is now incorrect, by as much as 32 seconds, but at least 1. a, produces information Ia with timestamp ta Ia(ta) c c, also consumes information Ia(ta)

Solution All sites obtain leapsecond information from the same information source Use R-GMA Only need one node to obtain data from USNO ftp site. This node will publish information via a DBProducerServlet Timestamp class will use this information to convert between formats

Solution (part a) DB Producer Servlet Consumer Servlet Application U.S.N.O. Leapsecond prod DB Producer Consumer Servlet SQL-DB Consumer Timestamp obj Leap Second data Application (Local Persistent Cache)

Solution (Part B) ASCII to binary conversion ASCII ta -> Binary tb Find corresponding leapsecond value, L for ta Corrected binary value = tb + L

Solution (Part B) Binary to ASCII conversion Binary ta -> ASCII tb Find corresponding leapsecond value, L for ta Corrected binary value = tb - L Easy to reverse engineer the ASCII fields from the binary second amount

Solution (Part B) Must decide upon Binary and ASCII second fraction format. UNIX binary fraction is given as the elapsed micro-seconds (resolution not good enough for future applications) GGF were proposing a binary fraction of a second value (regressed to ASCII only) IETF only have a decimal fraction of variable length

The Earth Was Created 4 Billion Years Ago… Must decide on an epoch for binary timestamps NTP = 1/1/1900 TAI = 1/1/1958 UNIX= 1/1/1970 UTC= 1/1/1972 GPS = 1/1/1980 Y2K = 1/1/2000 Most sensible TAI, UTC or Y2K UNIX unsatisfactory -- non-integer offset ! Easy to convert from others

To do… Decide upon Performance evaluation Epoch Binary fraction of second format Will there be accuracy/resolution info Performance evaluation Conversion times Optimise field extraction & testing Cron scripts for obtaining data?