Denote timezone in ISO 8601 when using date only

Question

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月11日T14Z

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.

• Matt Johnson-Pint: What is a "media label" in this context? Do you mean like a physical sticker on the side of a CD-ROM? Could you please be more specific about how this applies to software, and your use case in particular? Thanks.
• Matt Johnson-Pint: Also, just FYI - 2024年01月11日T14Z would be invalid by ISO 8601. A combined representation must include hours and minutes at minimum. ie, 2024年01月11日T14:00Z.
• leetbacoon: @MattJohnson-Pint We use GNU/Linux for all systems and permit all characters in filenames except / and NUL. These dates will be printed on paper labels on ODA cartridges & LTO cartridges, and in filenames of tarballs. ............ We used this site for guidance and found 2024年01月11日T14Z to be valid. It's difficult to confirm/deny validity for us currently. The site is perhaps incorrect?
• Matt Johnson-Pint: Just double checked my copies of the ISO 8601 spec and it appears I was mistaken. It is indeed valid as a "reduced representation" to have only hours and omit the minutes. Sorry about that!
• leetbacoon: The confirmation and details are appreciated @MattJohnson-Pint. We use dates to specify the point at which the data within the archive is deemed complete (publish date in a sense). So, a tarball with 2024年01月11日 date in filename means that is when we began to create the tarball, and everything inside it was OK at that date. It may take multiple days to complete but would still have 2024年01月11日 on paper label and filename. Thanks for helping us think about how we utilise dates/datetimes.

Answer 1

ISO 8601年1月20日19§5.2.2.1 (previously ISO 8601-2004§4.1.2.2) covers "complete representations" of calendar dates, which allows for only two formats:

• A basic format that is [year][month][day], ex: 19850412
• An extended format that is [year]-[month]-[day], ex: 1985年04月12日

There 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月11日T00:00:00, 2024年01月12日T00: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月11日T00:00:00Z, 2024年01月12日T00: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月10日T00:00:00-08:00, 2024年03月11日T00: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月07日T00:00-04:00, 2024年09月08日T01: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.

TL;DR : Dates don't have time zones.

• Matt Johnson-Pint: I'll also add that our modern concept of a "time zone" is relatively new - starting in the 19th century. We were keeping dates on calendars far before then.
• leetbacoon: I appreciate the in-depth answer. Could you please explain why a date like 2024年01月11日 assumes the range [2024年01月11日T00:00:00Z, 2024年01月12日T00:00:00Z) and not [2024年01月11日T00:00:00Z, 2024年01月11日T23:59:59Z)?
• Matt Johnson-Pint: It doesn't. Without being applied to a time zone, it only implies [2024年01月11日T00:00:00, 2024年01月12日T00:00:00) (no Z).
• Matt Johnson-Pint: That's why it's a half-open interval. Just like [1,2) includes 1.999999999 but not 2, a half-open timestamp interval includes 2024年01月11日T23:59:59.999999999 but not 2024年01月12日T00:00:00. Google search about "half-open intervals" and "number lines". The [ (or a solid filled circle) represent inclusivity, while the ) (or an open empty circle) represents exclusivity.
• Matt Johnson-Pint: There are two benefits of this. 1) you can subtract end - start and get a whole number, not some fractional result, and 2) you can line up one interval after the next and have no gaps.