0

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.

Improve this question
6
  • 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. Commented Dec 13, 2024 at 0:08
  • Also, just FYI - 2024-01-11T14Z would be invalid by ISO 8601. A combined representation must include hours and minutes at minimum. ie, 2024-01-11T14:00Z. Commented Dec 13, 2024 at 0:22
  • @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-11T14Z to be valid. It's difficult to confirm/deny validity for us currently. The site is perhaps incorrect? Commented Dec 13, 2024 at 23:15
  • 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! Commented Dec 14, 2024 at 0:21
  • 1
    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. Commented Dec 14, 2024 at 0:41

1 Answer 1

Reset to default
2

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:

  • 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-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.

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

Improve this answer
Sign up to request clarification or add additional context in comments.

6 Comments

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.
I appreciate the in-depth answer. Could you please explain why a date like 2024-01-11 assumes the range [2024-01-11T00:00:00Z, 2024-01-12T00:00:00Z) and not [2024-01-11T00:00:00Z, 2024-01-11T23:59:59Z)?
It doesn't. Without being applied to a time zone, it only implies [2024-01-11T00:00:00, 2024-01-12T00:00:00) (no Z).
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-11T23:59:59.999999999 but not 2024-01-12T00: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.
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.
|

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.