4 ms·
> I think instead you'd send a timestamp (unix or NTFS or TAI or other) annotated with "Norway" This is what I attempted to write with "2023-10-29T02:15NO" (NO
by magicalhippo 3y ago
> I think instead you'd send a timestamp (unix or NTFS or TAI or other) annotated with "Norway"
This is what I attempted to write with "2023-10-29T02:15NO" (NO being Norway's country code).
> Am I that bad at explaining this?
Could be I'm dense, and it's not my field of expertise.
Let's say Norway has decided to change it's offset from +01:00 to +01:15 at 2024-01-01T01:00:00Z. I have a process that records timestamps, and lets imagine it records them with the suggested named offsets instead of numerical offsets, in the format shown above.
Later next year, you look in the logs and see 2024-01-01T02:07:00NO. How do you know which time this is in UTC?
With numerical offsets this is simple, because it would either be recorded as 2024-01-01T02:07:00+01:00 or 2024-01-01T02:07:00+01:15. But when you just have NO, how to you convert the timestamp to UTC?
- Dylan16807 3y agoA Unix/NTFS/TAI timestamp would not be affected by the offset. Using Unix as the example: 2024-01-01T02:07:00+01:00_NO -> 1704071220_NO 2024-01-01T02:07:00+01:15_NO-> 1704070320_NO The timestamp doesn't have to be UTC, but it should specifically not be local time. You should be able to convert it to UTC without knowing the offset or time zone. So, done this way, storing time zone and no offset is unambiguous. And it gives you more information than storing an offset and no time zone.
- magicalhippo 3y agoThanks, yes that makes sense. I was working under the assumption that ISO 8601 was meant to be human-readable. If you can forego that requirement, then the solution you present would work well indeed.