Stop using alternative colon and alternative slash on video filenames

[rafaellehmkuhl]

Those are not well known which could be a problem on parsing, and @joaoantoniocardoso suggested that on compressing/decompressing those files will have those characters changed as they are Unicode.

[rafaellehmkuhl]

@ES-Alexander @joaoantoniocardoso it would be cool to have you guys input for an alternative timestamp format.

[ES-Alexander]

This frustrates me to no end, because both the relevant standards (ISO8601 & RFC3339) have only formats that are either nicely readable or highly compatible as a filename. That's exacerbated by the fact that people tend to like their timestamps to be localised to where the file was created, but consistent lexicographic sorting technically only orders correctly if the timestamps are all expressed in the same timezone, which is easiest to ensure compatibility for by using UTC (at the cost of intuitive understanding of the actual times).

I guess the main questions are about which properties are important, so here are my preferences:

• For data alignment purposes I think specificity is important, so I think . should be reserved for the decimal indicator for seconds (to avoid confusion), and for the file extension (since that's non-negotiable)
• Sorting is valuable, so the element order should definitely be from largest to smallest by the quantities being represented, but I personally think localisation is more important than strict sorting and simplified parsing, so I like the idea of localised times with a timezone indicator at the end (e.g. +1100 or -0700)
  • It's worth noting that not including a timezone specifier makes it unclear whether or not a timestamp is localised, which makes it easier to interpret them incorrectly
  • Also, including a numeric timezone specifier means softwares don't need to use any complicated timezone map/region libraries to determine what the correct offset is given the location and time of year
• I find the ISIO8601 central T to be unintuitive to read, and if we can't fully embrace the format then I think it's fine to replace that with an _ instead
• I think separating at least the "date" portions is important, and I find it quite intuitive to use the iso - separator for that
• Separating the "time" portions is a nice to have, but I think not essential, and there isn't a great separator if _, -, and . are already used for other adjacent purposes

From all that my preference is timestamps that look like YYYY-MM-DD_hhmmss.sss±ZZZZ, e.g. 2023-08-11_165107.123+1100