IClock is intended for use anywhere you need to have access to the current time.
Although it's not strictly incorrect to call SystemClock.Instance.GetCurrentInstant() directly,
in the same way as you might call DateTime.UtcNow, it's strongly discouraged
as a matter of style for production code. We recommend providing an instance of IClock
to anything that needs it, which allows you to write tests using the fake clock in the TimeMachine.Testing
assembly (or your own implementation). [...]
A date and time in a particular calendar system. A LocalDateTime value does not represent an
instant on the global time line, because it has no associated time zone: "November 12th 2009 7pm, ISO calendar"
occurred at different instants for different people around the world. [...]
The units within a period. When a period is created to find the difference between two local values,
the caller may specify which units are required - for example, you can ask for the difference between two dates
in "years and weeks". Units are always applied largest-first in arithmetic.
Singleton implementation of Clock which reads the current system time.
It is recommended that for anything other than throwaway code, this is only referenced
in a single place in your code: where you provide a value to inject into the rest of
your application, which should only depend on the interface.
Exception thrown to indicate that a time zone source has violated the contract of IDateTimeZoneSource.
This exception is primarily intended to be thrown from DateTimeZoneCache, and only in the face of a buggy
source; user code should not usually need to be aware of this or catch it.