Add additional time types

[sdhiscocks]

Created from discussions by @apiszcz, @sdhiscocks and @DavidFCrouse in #170.

[sdhiscocks]

Regarding time zones and the like,

Observation/comment: Recently I continue to experience learning with date aware time zones, the StoneSoup state datetime is not timezone aware, most would think UTC would be the standard is good. I am finding that I need to produce timezone aware for other reasons, database storage, etc., so possibly another state property to consider or option for state.
For now:
state_timestamp_withtimezone = pytz.utc.localize(state.timestamp)

I will disagree with this. While I see that Stone Soup makes extensive use of the datetime class, that is convenient, but not 100% ideal. It is fine for basic simulations, but you probably wouldn't want to model anything critical that way and timezones would just make it wore. As I understand it, the datetime class bases things on UTC. However, the leap seconds in UTC could potentially cause problems. For example, think of the timescale in GLONASS versus GPS. GPS reports a time and then a leap second offset. GLONASS reports UTC. However, when a leap second is added, that means that there is suddenly an extra second in the count from what you get from GLONASS. It can be handled, but it is inconvenient. The real issue is that if you use UTC, you must always keep your software up to date to keep track of the leap seconds.

I would say that an ideal timescale would be terrestrial time (TT), which is in the IERS standards. One can provide their own conversions to any other timescale as desired, included different timezones. There is a lot of overhead that comes with programming in timezones. Using a local time as a timestamp for something isn't great: how are you going to uniquely represent a time at the changes for daylight savings time? Daylight savings time is not at the same time in Europe and the United States. Some countries do not have it at all. Also, timezones themselves can be complicated by political boundaries.

The simplest thing would be to store the time in terrestrial time, which has no leap seconds. For conversion to other timescales, one can use something like the functions in the International Astronomical Union's Standards of Fundamental Astronomy. As for local time and the like, just let the user provide his own stuff. Do you really want to differentiate between things at a granular level, such as different counties in the U.S. state of Indiana observing different times? I think not.
https://en.wikipedia.org/wiki/Time_in_Indiana

That said, using terrestrial time would require bypassing the datetime class. For basic simulations, UTC suffices. Just don't be surprised if you get a blip when a leap second is added, depending on how you handle the times. I say, keep it the way it is and add a note about leapseconds and local time to the documentation.

Thanks for your comments @DavidFCrouse.

So in Stone Soup, we don't specify a type for timestamp, as this will only be dependent on timestamp type that is specified on detections. Therefore, timestamps that include timezones (as you raised @apiszcz) should work fine, or a timestamp type that addresses points you raise should be possible.

I think the only constraint is we use datetime.timedelta types, so a datetime.datetime subclass or other custom type should be aware of these for addition and subtraction operators.

[apiszcz]

FYSA: Python 3.9 new feature
https://docs.python.org/3/library/zoneinfo.html