Alternative to colon in a time format

Question

ISO 8601 recommends the following format for a date and time:

2014-12-29T16:11:20+00:00

I'm rather fond of this format since it allows for lexical ordering. But there is a small problem: some file systems don't allow colons in file names (at least not normally). ISO 8601 does allow for omitting the colons, but I would rather have some symbol there than have the numbers run together:

2014-12-29T161120+0000

Does ISO 8601 allow for a symbol other than colons? I couldn't find any indication that it does. If not, is there another well recognized symbol I could use? (Perhaps another standard proposes such a symbol?)

Gerger

So there you have it. Colons or nothing. (The wiki article does a fairly good job of highlighting the accepted forms shown in boxes on the right.) – Odetteodeum

I propose a format based on ISO 8601 in a post at blog.xam.de/2016/07/… -- would make our world easier, if we could agree on a format :-) – Aquacade

Answer 1

There is none.

ISO 8601 only allows for a colon (:) for separating time components in the extended format:

The basic format is [hh][mm][ss] and the extended format is [hh]:[mm]:[ss].

There is no provision for an alternate extended format.

Odetteodeum

"If not, is there another well recognized symbol I could use? (Perhaps another standard proposes such a symbol?)" So there's no other widely recognized symbol, either? – Gerger

Then it wouldn't be ISO 8601. You can use whatever symbol you like in your own format. But no: unlike dates, times are pretty much exclusively separated with colons, if anything - this has filtered down into the format standards. The other "web standard" would be RFC 822/1123. – Odetteodeum

Answer 2

There's no other provision and you cannot have a complete datetime expresion with the first half in extended and the last one in basic formats; they must have the same formats.

A workaround, and i emphazise in workaround, is to split the string with something else, e.g., a period or underscore, that separates two valid expresions, the date in extended format and the time in basic format: e.g., myfilename_2020-12-13.T0006Z_otherNotes.ext or myfilename_2020-12-13_T0006Z_otherNotes.ext.

You must be clear with other parts involved in the usage of such files - mainly speaking about machine ones - in that it is not a complete datetime expresion, but 2 valid ones each one in different formats - extended, then basic - separated by an agreed and unambiguous character (i mentioned a period/underscore instead of a dash/hyphen specifically for this reason).

The obvious downsides of this approach are: the time part is harder to read and some other people could believe you badly implemented the ISO or you have poor understanding of it, when not.

The good sides... it works in Windows, it organizes the elements in the filesystem in the right order, despite the OS, it follows the ISO standards (in a special way) and it is compatible with machines (from scripts to AIs and everything in the middle).

It is a workaround. I repeat.

As a final note, i really wonder why the people doing ISO 8601-2019 didn't consider the problem that is using ISO in filenames or if they're totally unaware of it.

Vizzone

Answer 3

For combined date and time representations you must use basic format for both date and time or extended format for both date and time representations to comply with ISO 8601.

Examples of ISO 8601 compliant date and time representations:

2020-12-03T15:05:57+00:00 (extended)
2020-12-03T15:05:57Z (extended)
20201203T150557Z (basic)

For maximum compatibility with various operating systems file naming requirements and ISO 8601 compliance I think the last example or something similar should work.

Reference: https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations

Bowie