Refine time representations

[AngusGMorrison]

This PR makes several updates to the structure of the time package and its associated structs.

Rationale

• Update naming conventions to reflect standard use
• Clarify the distinction between UTC and the continuous timescales
• Improve type safety where specific timescales are required (as opposed to any Time variant)

Design

UTC

dates::Time is now utc::UTC, and is intended only for use as an IO time to be converted to one of the continuous timescales. This gives the user the freedom to specify a time in human-readable format (to attosecond precision) while excusing us from worrying about time zones other than UTC. The correctness of the user-provided UTC with regard to leap seconds is explicitly the user's responsiblity.

utc::UTC functions identically to the former dates::Time, but has some internal structural changes that leverage the type system to ensure that each time field falls within a valid range.

ContinuousTime

epochs::RawEpoch is now continuous::ContinuousTime to emphasise that it is the basis of all continuous timescales. A comment has been added explaining its intended use.

Internally, the attoseconds field is now a u64 and the sign of the ContinuousTime (i.e. before or after some arbitrary epoch) is determined exclusively by the sign of the seconds field.

Delta

A continuous time Delta struct has been added, along with operator overloads for adding and subtracting Deltas from ContinuousTimes. This is a prerequisite for converting between timescales.

Time

epoch::Epoch is now continuous::Time, reflecting modern usage of the word "epoch".

Rust's type system doesn't allow us to require a specific enum variant as a function parameter (i.e. a parameter may be of type Time but cannot be of type Time::UT1). For this reason, each variant now embeds a dedicated struct of the corresponding time type, e.g. UT1, TCB, etc. This is required to support functions that require a time in a specific timescale to do so in a type-safe way without requiring a match statement to identify the specific time variant that has been passed by the user. The match statement approach is problematic: since conversion between arbitrary time scales often requires non-constant inputs (e.g. 𝚫UT), a function accepting an arbitrary Time variant would also have to accept all possible parameters required to convert between any variant and the required timescale for the current calculation.

[helgee]

LGTM modulo naming nitpicks.

[codecov]

Codecov Report

Attention: 31 lines in your changes are missing coverage. Please review.

Comparison is base (739a847) 97.69% compared to head (29063ae) 97.84%.

Files	Patch %	Lines
crates/lox_core/src/time/continuous.rs	97.44%	27 Missing ⚠️
crates/lox_core/src/time.rs	97.72%	2 Missing ⚠️
crates/lox_py/src/lib.rs	0.00%	1 Missing ⚠️
crates/lox_py/src/time.rs	96.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #44      +/-   ##
==========================================
+ Coverage   97.69%   97.84%   +0.15%     
==========================================
  Files          40       42       +2     
  Lines       16273    17322    +1049     
==========================================
+ Hits        15898    16949    +1051     
+ Misses        375      373       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.