[kstenerud]

It's not quite so cut-and-dry. UNIX timestamps unfortunately don't solve the problems of time because they don't contain enough information.

Time is something that developers get wrong more often than any other type. Your time data requirements change as your use case for the time changes.

From https://github.com/kstenerud/compact-time/blob/master/compac...

Aside from issues of synchronization, leap seconds, data container limitations and such, it's important to choose the correct kind of time to store, and the right kind depends on what the purpose of recording the time is.

There are three main kinds of time:

*Absolute Time*

Absolute time is a time that is fixed relative to UTC (or relative to an offset from UTC). It is not affected by daylight savings time, nor will it ever change if an area's time zone changes for political reasons. Absolute time is best recorded in the UTC time zone, and is mostly useful for events in the past (because the time zone is now fixed at the time of the event, so it probably no longer matters what specific time zone was in effect).

*Fixed Time*

Fixed time is a time that is fixed to a particular place, and that place has a time zone associated with it (but the time zone might change for political reasons in the future,for example with daylight savings). If the venue changes, only the time zone data needs to be updated. An example would be an appointment in London this coming October 12th at 10:30.

*Floating Time*

Floating (or local) time is always relative to the time zone of the observer. If you travel and change time zones, floating time changes zones with you. If you and another observer are in different time zones and observe the same floating time value, the absolute times you calculate will be different. An example would be your 8:00 morning workout.

*When to Use Each Kind*

Use whichever kind of time most succinctly and completely handles your time needs. Don't depend on time zone information as a proxy for a location; that's depending on a side effect, which is always brittle. Always store location information separately if it's important.

Examples:

Recording an event: Absolute

Log entries: Absolute

An appointment: Fixed

Your daily schedule: Floating

Deadlines: Usually fixed time, but possibly absolute time.

[lolc]

Interesting to see fixed and floating time differentiated. I didn't really have a name for that last concept.

And fixed time I would call local time. Why call it fixed? Because it's tied to a location?

[kstenerud]

I avoided "local" because the name could technically be claimed by both types: "It's called -local- because it's local to a particular zone" vs "It's called -local- because it's local to my current (local) zone."

So I went with floating vs fixed because it feels less prone to ambiguity. "Fixed" is fixed to a particular zone, and "floating" floats along with me as my current zone changes.