travis-ty - Time formats are difficult and require OS and application/website regular maintenance (Y2K, 2038, short term decisions and long term issues)

travis is a great service that provides CI (Continuous Integration) build platform suitable for github based projects. For Open-Source projects, there is a free tier.

 - but there was a wee booboo if the end-time of a build is not yet set:

This could be case of defaulting to the start of Unix time or 'epoch'. Unix time is measured from the beginning of the year 1970, measured in seconds. An alternative implementation would be to use a null to indicate unknown time - however even the inventor of null considers it to be a mistake. This being a website, the client side code must be JavaScript, in which there is another option undefined, although normally that is used to indicate a bug for example if attempting to access part of the program that does not exist. (for example, a typo attempting to use a function that does not exist). This is possible, because JavaScript is a dynamically 'duck typed' language, where objects and data are accessed by convention rather than by compile time 'hard checks'

Depending on the implementation in code, the use of Unix time also has had a problem around the year 2038, somewhat similar to the infamous Y2K (Year two thousand) problem, where not enough storage space was set aside for years beyond 1999. With the year 2038, Unix time requires more than 2³¹ seconds beyond epoch (start of 1970). Unfortunately, some implementations used a signed 31 bit integer to store the number of seconds, and so the maximum time offset is reached in the year 2038, January 1st, at 03:14:07 UTC on 19 January 2038. One second later, the integer will overflow, the most significant bit is set, and so the offset becomes negative. The stored time will then be interpreted as 2³¹ seconds before epoch, which is a time near the beginning of the year 1901.

The wider field of engineering has many such examples of short-term decisions leading to longer-term issues. Examples in Civil engineering abound: the limit decided on truck sizes that could pass through the Chunnel under the North Sea, deciding a limit to capacity between the UK and the continent. Another example is the sewage processing plant of Ringsend, Dublin, which unfortunately has in a short few years been surpassed by demand. Pragmatists would say that for any real system to be built, there are always shortcomings due to necessary trade-offs between cost vs capability: without such limits placed on capability, the costs could mean that the software or sewage plant or tunnel would never actually get built. Since economies and populations and computer hardware capabilities generally grow over time, it is inevitable that some practical limit decided today will at some point seem unnecessarily limiting at some point in the future.

The answer seems to be maintenance: a system build in the 1970s needs maintaining to upgrade to the newer times (sometimes, literally!), given that the system has successfully survived so long.