propensive / aviation Goto Github PK

For testing, it would be useful to provide a clock which is stopped, but has a manual tick method for advancing it. This will need to ensure that any methods which measure time make reference to the clock. It's not clear if this is possible.

Instead of using System.currentTimeMillis, this would give the impression of the "current time" being an input to a pure function.

It should be possible to represent recurrent events which repeat periodically

It should support repetition with multiples of:

• annually
• monthly
• weekly
• daily
• hourly
• minutely
  where the repetitions are determined by,
• at a numbered second in a minute
• at a numbered minute and second in an hour
• at a given time in a day
• on a given day each week
• on a given date each month
• on a given week and day each month
• on a given week number and day each year
• on a given date each year
• on a given week in a given month each year

Combinations of these should most scenarios, though others may remain...

Undated times can be represented in terms such as 2.05.pm or 12.00.am but by default, it's not possible to disambiguate between 2.0.pm and 2.00.pm where the former should be seen as an invalid time. A macro can be used to check this.

RFC3339 defines a format for durations.

Modified Julian Date, apart from having a fixed 2400000 offset from the Julian Date, uses midnight as its basis rather than noon.

Leap seconds cause all kinds of problems.

UNIX time increases by 86400 seconds every day, even on days when there is a leap second. On these days, the same numerical time can ambiguously represent distinct times (one second apart). This can affect calculations involving durations which span leap seconds.

Conversely, TAI does account for leap seconds.

I think that internally representing an Instant as TAI or UNIX time are both viable, and new instances of Instants in either representation could be constructed from UNIX timestamps or TAI timestamps, potentially raising ambiguity issues.

The easiest way to implement this would be to wrap java.util's Date and related classes.

The name "Temporaneous" was always a bit too direct.

This document provides detailed calculations.

Anticipation provides a typeclass interface for time, and we should provide instances for it.