We're working on system backups and want to use ISO 8601 dates on media labels. We're at a tossup between whether or not a date like 2024-01-11 is using local time or UTC (which is not local in our timezone). We want to use UTC and specify that when it is, and make it clear when it isn't. The ambiguity is a problem.
The next best alternative we've found is to include the hour so a timezone can be properly stated:
2024-01-11T14Z
Is there a better way? We don't have access to ISO 8601 documentation so we're struggling to come to a valid conclusion. We prefer not to use the hour (just the timezone identifier) unless there really is no other way.
ISO 8601-1-2019§5.2.2.1 (previously ISO 8601-2004§4.1.2.2) covers "complete representations" of calendar dates, which allows for only two formats:
[year][month][day], ex: 19850412[year]-[month]-[day], ex: 1985-04-12There are further reduced representations (ie., year only, or year+month only), but there are no representations for calendar dates that include a time zone.
Time zones don't come into play until a time of day is involved. In other words, calendar dates do not have time zones.
This is logically congruent with the concept of a calendar date in the physical world. Suppose I handed you a typical paper calendar, having 12 pages - one for each month of the year. Each page has a square with the calendar date noted on it. If pointed to a square and asked you "what time zone is this in?" you would probably think I was speaking nonsense.
Another way to think about dates is as a representation of a range of time in an arbitrary undefined time zone (what ISO 8601 calls "local time"). For example, 2024-01-11 is equivalent to the half-open interval [2024-01-11T00:00:00, 2024-01-12T00:00:00). There's still no time zone involved.
However, once we apply that range to a specific time zone (or UTC) - then we can start denoting it with time zone offsets. In other words, 2024-01-11 with regard to UTC is equivalent to [2024-01-11T00:00:00Z, 2024-01-12T00:00:00Z)
This application is trickier than you may think, due to daylight saving time and irregular time zone adjustments. Consider 2024-03-10 when applied to US Pacific Time. That would be equivalent to the range [2024-03-10T00:00:00-08:00, 2024-03-11T00:00:00-07:00) - note the offset change because that is the day DST starts in that particular time zone.
For even more complexity, consider 2024-09-07 when applied in Santiago, Chile. That's equivalent to [2024-09-07T00:00-04:00, 2024-09-08T01:00-03:00). That's because the date 2024-09-08 was the start of DST in Chile, and the transition occurred exactly at midnight. In other words, at the start DST on that day in Chile, midnight did not exist. The day started at 01:00 instead. So the time range for both the DST transition day and also the prior day are affected.
With these sorts of complexities in mind you can see how if a date were to have a time zone offset included, it would possibly be ambiguous. As yet another example, if I gave you the value 2024-03-31+00:00 - you might think that meant +00:00 was applicable for the entire day. It would if you were applying it to Iceland, but it wouldn't if you applying it to England. In England, on that date, only the first hour of the day was +00:00 - the rest of the date was +01:00 due to the start of British Summer Time.