Yeah, dealing with date is not that simple. As you mentioned, geolocation is not encoded in Date/DateTime format, I see it as an extra data required to properly resolve the date value. For example, in Rails in order to properly parse a date time value on the desired timezone I could use:

Time.use_zone(“Hawaii”) { Time.zone.parse(str) }
# or
Time.use_zone(“Hawaii”) { Time.zone.at(timestamp) }

The idea of using Unix time or ISO8601 is to provide data that can be properly recovered no matter the consumer timezone, because it is not my concern.

Not sure if I answered your question.

Unix time considers positive integers since 1970, but negative ones represents prior to this date. There is not problem in using ISO8601, it is just a matter of preference. As I pointed, ISO8601 is human readable so it is easy to reason about the date, if debugging for example.

However, in general this info is consumed programmatically, so it doesn’t need to be readable, it just need to correct.

Conversely, if Unix time is OK then what’s wrong with ISO8601-normalized-to-UTC?

While the offset in minutes (-0300) might accurately reflect Brazil, you’ve actually lost the relevant time zone id of the country.

For example, try resolving the local time taking into account the DST (daylight savings time), ie: can you accurately print 10am HAST or HADT? What about countries that share the same longitude but use different time suffixes for their language locale?

While I’ll be the first to admit that Date/DateTime don’t actually encode a geographic location (whether it’s a Windows TimeZone Id or IANA/Olson TZDB key), I wish it did.