> That's missing the point. That's like arguing if DD/MM/YYYY or YYYY-MM-DD is the format.
Not really. We’re talking about unambiguous storage and transmission of date time. Epoch has the big problem that it only makes sense on the system that generated. By itself an epoch doesn’t contain enough data to decode it correctly, and be certain your interpretation is correct. With a date-time format like ISO 8601 you need no further information to decode the time correctly to a human relevant time reference. Even if you don’t know the exact format used, it’s usually possible to figure it out if your have enough examples, the same isn’t true of epoch.
> Just implementation details that don't affect anything
Hahaha, oh god. Those entire article and discussion is all about implementation detail of date time storage, and why it does effect things. For the epoch unit it matters is your want two systems to communicate with each other. It’s a total pain in the arse working with epoch because every platform and language handles epoch times subtly different. Units in particular and really mess you up, especially when multiple systems have different levels of precision.
> True. But it depends what you mean. If you scheduled a world wide meeting then you probably want offset. If the meeting is defined as "five minutes past noon in New York" then UTC and offset be damned.
Every meeting involving humans involves a physical location (the humans have to at least physically occupy the space in front of cameras) the same . So you need pick somewhere, the host location would be the obvious choice.
> Like I said, you still need to be careful.
Great, so your contribution to this topic is to state the obvious, then say be careful, edge cases exist. How does that add to a conversation about an article that’s actually exploring those edge cases?