Comment by Terr_
3 days ago
> in the end it's a presentation issue.
Whoah there, no, that's a huge pitfall of sharpened spikes as soon as you deal with events in the future.
If someone proposes an after-work party for "5:30 PM" at the Latverian office in Latverian time, that's not a fixed offset of seconds from now, it's actually a set of triggering conditions.
We can make a decent guess about when those conditions will be satisfied, but don't actually know until it finally happens. At any moment, the administration of Dr. Doom could arbitrarily change the country's clocks. They might skip over that entire hour, or the hour might repeat on that day, or the entire country might cease to exist.
Making a prediction in UTC and storing just that is a very bad idea, because you lost all the original context you need to recalculate a better prediction as things change. Storing the "5PM in Latverian" is how we keep that context.
Here the problem is that past "time" values and future "time" values should be different data types, e.g. "Time" and "FutureTime".
A past time value (e.g. the times of logged events) actually is a time value that is known and it should be stored as a TAI or UTC value and when desired it can be converted to any date/time format for presentation purposes.
In most cases, a future time value is not a known time value yet and it must be stored as a more complex data type, at the minimum including the local time and the time zone, but for more distant future dates preferably also including the exact geographic location, for the eventuality of changes in the time zone laws.
Therefore, both you and the poster to whom you have replied are right, but you are right only when talking about future time values, while the other poster was right only when talking about past time values.
This is not about "future" or "past" dates but (to use Temporal as a common language) whether the date is an Instant or a ZonedDateTime conceptually.
I think that's essentially what you mean, but it's an important distinction. It's use-case based. Making a data type time-based will not simplify, but only complicate things.
[0] https://tc39.es/proposal-temporal/docs/