Why do you prefer UTC? I feel storing plain unix times is simplest since there's no time zone information at all. And there's no possibility of forgetting a conversion, since (with most languages/libraries) different types are used for plain unix times vs. local times.
Just to be make sure we're talking about the same thing, by "plain unix time" I mean something like java.time.Instant, and by "UTC time" I mean something like java.time.ZonedDateTime with zone == UTC.
With ZonedDateTime, there's obviously a time zone field. We can have a convention of always setting it to UTC, but that introduces a possible source of bugs. We might call ZonedDateTime.now() and forget to pass an explicit zone. Especially if the author is a new contributor who hasn't been told about our convention.
Or we might use a library which produces ZonedDateTimes with the system's default zone. Then we have to canonicalize them at some point, and be very careful not to rely on the local date/time info prior to canonicalization.
I'd rather just use a type like Instant which has no time zone field, so that there's no need for any time zone convention.
Further, we might need to serialize a timestamp using a non-UTC timezone, say CST which is common in payments systems. If we're using UTC times, we might forget to convert from UTC to CST. If we're using a plain unix time, we're forced to specify a time zone when serializing, so it's harder to make a mistake.
Comments
Why do you prefer UTC? I feel storing plain unix times is simplest since there's no time zone information at all. And there's no possibility of forgetting a conversion, since (with most languages/libraries) different types are used for plain unix times vs. local times.
There's no time zone information in UTC either. People often mistake UTC for a time zone, but it isn't actually one.
Just to be make sure we're talking about the same thing, by "plain unix time" I mean something like java.time.Instant, and by "UTC time" I mean something like java.time.ZonedDateTime with zone == UTC.
With ZonedDateTime, there's obviously a time zone field. We can have a convention of always setting it to UTC, but that introduces a possible source of bugs. We might call ZonedDateTime.now() and forget to pass an explicit zone. Especially if the author is a new contributor who hasn't been told about our convention.
Or we might use a library which produces ZonedDateTimes with the system's default zone. Then we have to canonicalize them at some point, and be very careful not to rely on the local date/time info prior to canonicalization.
I'd rather just use a type like Instant which has no time zone field, so that there's no need for any time zone convention.
Further, we might need to serialize a timestamp using a non-UTC timezone, say CST which is common in payments systems. If we're using UTC times, we might forget to convert from UTC to CST. If we're using a plain unix time, we're forced to specify a time zone when serializing, so it's harder to make a mistake.
Unless your users are happy to view UTC you will have to deal with it when you display it to them.