By "several filesystems", you mean Windows? NTFS can handle it, but Windows can't (presumably due to using it for drive letters).

':' was the traditional directory separator on Macintosh systems before OSX, therefore it can't be used on HFS+ either. I remember there being some FS funk when OSX came out since it was very common for people to put dates in their filenames using slashes, and well, UNIX doesn't like that. I don't know what APFS does.

As I understand it, : and / get swapped depending on whether you use unix APIs (/ is a directory separator, : is plain) or mac APIs (: is a directory separator and / is plain)

From what I recall (had a macbook years ago) I could put colons in filenames in the terminal, but not in finder.

NTFS can't have colons in filenames because they are used to name alternate data streams.

https://docs.microsoft.com/en-us/sysinternals/downloads/stre...

Also HDFS. This bit me the first time I tried to write a Hadoop job that wrote every run to a new output dir.

Fun fact: If you download a file containing colons with popular web browsers, they'll try to be helpful and will replace the colons to avoid problems storing the file on filesystems which don't support colons. Took me a while to figure out why the browsers messed with the file names.

chrome's extension api for downloads has the same limitation

filenames that are reserved names on windows (like NUL) or contain characters that are reserved on windows are refused with "Invalid filename", even on platforms and filesystems that don't have the same limitations

this might be desirable for enforcing portability in extensions, but the thing isn't mentioned in the documentation[1] for the api so you had to know about it beforehand (like most extension devs, probably) or find out the hard way when some of your downloads unexpectedly fail (like me)

i was using it on linux in a personal extension i wrote, and i thought it was silly that i had to add extra code to further sanitize and mangle the filenames for an OS i don't even use

[1] https://developer.chrome.com/docs/extensions/reference/downl...

I use 2021-10-24T10_45_32_123456. Never had to store non-UTC so I'm not sure how I'd notate that. I don't use dots for fractional seconds because while that shouldn't get interpreted as an extension, some systems still do.

Me too, I'm usually using 2021-10-24--13-07-59

I use `--` to represent an en dash for date ranges (some_report_2021-01-01--2021-12-31). I don't use times nearly as often, but I separate date from time using an underscore in those instances.

My workaround has been to use alternate Unicode for colons[1] in filenames in Windows, along with similar substitutes for other illegal characters. For ease of input I use Autohotkey bindings (in this example: Alt+colon).

[1] '꞉' (U+A789). On my Windows systems the default typeface renders this identically to a regular colon.

I just wish there was proper support and UX for dates on file systems, so I can actually properly search for date ranges instead of having "iso8601 sorts lexicographically!" as a crutch used within filenames.

It doesn’t take long to get used to the basic format. 20211024T090755, etc.