Keeping in Time

Now it is 15:31 on the 11-09-2016 and I'm in London.

Writing and Reading dates #

Always use the order or full year, month then day of month.

• Text ordering is now time ordered
  • 2016-06-06 is always after 2015-06-07 in text and time
  • 06-07-2016 is before 07-06-2015 and after 05-06-2014 in text ordering, but not in time.
  • This useful in table ordering, like when listing files.
• Local differences don't matter so much (Europe vs USA format)

Offset Time #

The UK has British Summer Time, so that time point is 1 hour ahead of where it should be, so the time is actually 2016-09-11T15:31:00+01:00 (in ISO 8601 format).

Zoned Time #

If I asked you to call me at this time in 6 months, I might not appreciate a call at 2017-03-11T15:31:00+01:00 because I'm then out of Daylight Savings, so instead it's useful to capture the time zone.

Like this, 2017-03-11T15:31:00 [Europe/London] where Europe/London is an official (designation)[https://en.wikipedia.org/wiki/List_of_tz_database_time_zones] of my time zone. Except this isn't quite good enough...

What if I wanted a call at 2am on 29th of October, 2017?

2017-10-29T02:00:00 [Europe/London] happens twice and so to be as distinct as possible then perhaps 2017-10-29T02:00:00+00:00 [Europe/London] and 2017-10-29T02:00:00+01:00 [Europe/London] would be enough to know which is which.

GPS Time is ordered? #

Be wary of using GPS time. Although GPS time is an unadjusted series of seconds since a point in time, will it always be so? It's use case is for positioning and if there ever were a need, I would guess adjusting time to fix positioning would be preferred to adjusting positioning to fix time.

Use TAI time when you need time order or better use incrementing ids. #

You want to know about the series of events, such as, in a server log or transaction log.

The problem is UTC goes back in time and as Unix time typically uses UTC, your logs will too. https://en.wikipedia.org/wiki/Unix_time

But, it doesn't have to be this way: TAI time is ordered and not affected by adjustments to keep time in order with our solar cycle, so no leap seconds... that doesn't mean there aren't adjustments, but the adjustments should be such much smaller fractions of a second.

But, even with TAI, that fraction of a second can still get bigger: you don't poll NTP at a rate of a fraction of a second and PC clocks fall out of sync and on VMs sometimes more than expected.

So why not just use an incrementing counter? The order of log lines effectively does this, but assumes that they are written in order and kept in order, so I guess the question here is now that you aggregate your log files to central servers (Splunk, Logstash, etc) are they still in order of events or are they in order of adjustable time stamps.Summary

• For everyday usage use a Zoned Offset
  • 1999-12-31T23:59:59-04:00 [America/New_York]
• For scientific calculations use TAI, but how to distinguish from UTC?
  • 2017-03-11T14:31:36
• For strict ordering of events, don't use time: but keep a reference for indexing (finding the log lines)

• Next: Complex Primitives
• Previous: ICO has no powers over webcams