Handling time when programming

Handling time when developing can be tricky. Time calculations depend on imprecise and variable physical features (eg. leap seconds to account for the rotation of the earth) and socio-political features (eg. time zones) and this means there could be several pitfalls between expectation and reality when working with time.

UTC provides a uniform framework with which to look at time, abstracted away from the vagaries of local times. Interpreting UTC dates is mostly straightforward; issues only arise when converting UTC to local times. This is less of a problem for dates in the past (unless you look at historic dates, maybe older than a few decades or centuries i.e., before the epoch) and more of a problem for dates in the future.

Flavours of time: UT is a time standard based on the Earth's rotation; and UT1 is conceptually the solar time at 0° longitude but is calculated based on distant quasars because precise measurements of the sun are difficult. It is an accurate reflection (or as close as our technology allows) to the actual rotation of the earth. TAI is a time standard where every day is exactly 86000 seconds long, and is measured as the weighted average of about 400 atomic clocks around the world. GMT is mean solar time and is correlated to UT1, and may differ from UTC by up to 0.9 s. GPS time is TAI offset by 19 seconds and no leap second correction is applied. TAI is a reference timekeeping standard maintained by atomic clocks and is an abstract scale disconnected from physical reality. UT1 is solar time and is correlated to actual physical reality, to the rotation of the Earth which is variable from day to day. UT1 is correlated to reality but is inconvenient and irregular, while TAI is very convenient and regular - and thus UTC is based on TAI, but because TAI can go out of sync with UT1 from time to time, and because we cannot speed up the earth to make UT1 and UTC agree with each other, we instead use leap seconds to ensure UTC and UT1 are always within 0.9 seconds of each other. This means UTC is a discontinuous (because of leap seconds), abstract (because it is not perfectly correlated to the Earth's rotation), and reliable time-scale for almost all programming needs. Leap seconds are added about every year and a half on average.

However Unix time is affected by leap seconds and it handles these by 'replaying' the previous second - thus, each day has 86400 seconds and time goes backwards for a second. UTC does not replay seconds and instead has an extra second on days with a leap second for 86401 seconds. Unix time is measured as the number of seconds since the epoch (January 1 1970 in UTC) and is not affected by time zones or daylight savings. The start of the epoch is very close to the start of modern UTC timekeeping and representing and using precise dates from before this time can be challenging. Luckily that is rarely a problem for most projects.

Leave a Comment