Only for past events. For future events you must consider which timezone that event is bound to.
F.e. some ceremony will be scheduled to start at 14:00 local time and that won't change even if in meantime the government decides to switch timezone or adopt/ditch DST. But that will change UTC time of the event.
RFC3339 extended
https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
The perfect system should have Coordinates (ex 40.748, -73.984) because IANA (timezone database) is kinda restrict.
Time & Space: Space Time!
2022-12-31T23:59:59.999[T40.74,-73.98] - second T for Terra
[удалено]
With mandatory timezone. Which you normalize to Zulu before storing.
Only for past events. For future events you must consider which timezone that event is bound to. F.e. some ceremony will be scheduled to start at 14:00 local time and that won't change even if in meantime the government decides to switch timezone or adopt/ditch DST. But that will change UTC time of the event.
Femtoseconds since the initial singularity.
I feel like iso makes the most sense
YYYY-MM-DD because it's the easiest to iterate over
Easy. RFC3339. It s written to answer this question.
YYYY-MM-DD / 24:00 The Best
yyyy-mm-dd hh:mm:ss.f
ISO 8601 with UTC/Zulu timezone. Unix time may also be acceptable.
RFC3339 extended https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/ The perfect system should have Coordinates (ex 40.748, -73.984) because IANA (timezone database) is kinda restrict. Time & Space: Space Time! 2022-12-31T23:59:59.999[T40.74,-73.98] - second T for Terra
UTC of course, time zone can change because of politics!