4 ms·
I assume you mean UTC plus the latitude and longitude isn't UTC alone is enough?
by VMtest 5y ago
I assume you mean UTC plus the latitude and longitude
isn't UTC alone is enough?
- XorNot 5y agoIf you have a time for an event, then there's an encoded assumption about what you're trying to determine. Very few - I would say zero - events we want to know when they happened but don't care about where in anyway. For example when planning meeting times, the reason local time comes up is ultimately some determinant about when it's going to be day or night - that's the actual metric that meeting planning generally tries to take into account. Strictly speaking I would say this also applies for storing data about machine to machine events which might be normally considered to be purely sequence based. If we're storing times to determine processing order for example, then there'd be value in storing the lat/lon of the machines generating them, because it's an extra datum which can resolve expected ordering (i.e. based back-calculating latency windows).
- rswail 5y agoSo if I (in Australia) have a meeting with people in Thailand and Slovakia over Google meet, which is absolutely an "event we want to know when they happened but don't care about where in anyway", the local time(s) are all important when scheduling it for the future, but as a record of the event, it happened in all 3 locations simultaneously.
- XorNot 5y agoSure, but if you're trying to derive any useful information from that record as opposed to some CYA audit then you really want to have some local situational context for it. Personally when I'm arranging a meeting I want to know the local cultural context, and I want to know the relative times I'm asking for things there. Getting stuff done 2 hours later may or may not be possible based on the local time of day, calendar day, and time of year.