How to display Timestamps which are unambiguous?

Question

Problem: I need to name log files in such a way that the file name is unambiguous to humans.

---

My initial solution was to go from largest to smallest unit with zero padding each unit...

YYYYMMDDhhmmssuuuu.log

• Y - 4 digit year (2019-)
• M - 2 digit month (01-12)
• D - 2 digit day (01-31)
• h - 2 digit hour (00-23)
• m - 2 digit minutes (00-59)
• s - 2 digit seconds (00-59)
• u - 4 digit milliseconds (0000-9999)

Log files should always sort in the correct order (the larger the file number the later the time)

201912051357040042.log

I decided to add a few characters to make the name more human readable...

2019-12-05_13-57-04-0042.log

The actual time the log was written can be extracted using the rules above...

2019-12-05 13:57:04.0042

Ambiguity arises, however, when the hours are less than 13 since the hour hand of a clock can say 01 - 12 twice a day.

For example, the following future filename of...

2020-02-14_12-30-11-8675.log

could equally be assumed as written "super early on Valentine's Day" or "around lunch time on Valentine's Day"

Is there a way to name the log file so it's impossible to assume the wrong timestamp?

(the shorter the filename the better but you can assume no limit to the length of the filename)

All I can think of is this but maybe someone else has a more concise solution...

2020Y02M14D_12of23H30of59M11of59S8675of9999MS.log

Answer 1

Use the ISO format for combined date and time values.

It's best to stick to the standards, especially when dealing with dates.

The above linked Wikipedia article states (emphasis mine):

A single point in time can be represented by concatenating a complete date expression, the letter "T" as a delimiter, and a valid time expression. For example, "2007-04-05T14:30". It is permitted to omit the "T" character by mutual agreement as in "200704051430". Separating date and time parts with other characters such as space is not allowed in ISO 8601, but allowed in its profile RFC 3339.

The "valid time expression" it talks about is always written in 24-hour format, addressing your concern regarding ambiguity.

---

Thus, you'd likely be best off with using something in the form of:

2019-12-05T16:17:23.015.log _{^{(more readable)}}

_{^{As noted by @dosxuk, Windows and Mac both have issues with using the : character in a filename. If these are names of files, I'd recommend using the condensed format below.}}

or

20191205161723015.log _{^{(more condensed)}}

_{These forms also have the added benefit that the alphanumeric sort is also chronological.}

Answer 2

I take it this is unambiguous to a human reader rather than a machine?

The ISO 8601 is a good suggestion for machine readable/parseable data, but for human readability it's trickier. E.g. the US does dates with months and days swapped round, so in your example do you mean the 5th December or the 12th May? That's bit me a few times in the past - while the person/program outputting the log filenames may know the iso8601 format it's a longshot that all the users do...

I would take a hint from some guidelines e.g. material design's - https://material.io/design/communication/data-formats.html#date-time - display the month to remove that ambiguity and the am/pm status to remove the hour ambiguity

5th_Dec_2019_12-30-11.0042-PM (not perfect, the dot before the milliseconds isn't great for filenames, but it's a suggestion towards it, and consider if you want a timezone as well)

This of course loses the ability to sort chronologically by filename, your solutions here are either to rely on the file info generated with the log to sort them, or whack a machine readable number at the front of the filename such as a millisecond-precision unix timestamp. Here you can sort chronologically, and the last part of the filename is human readable and unambiguous.

15755490110042__5th_Dec_2019_12-30-11.0042-PM

Answer 3

I prefer to represent all of data in 2 digits as follows,

20Y02M14D12H30M11S86SS75MS.log

But if you have to keep year and millisecond in 4 digits then you might use the following one,

2020Y02M14D12H30M11S8675MS.log

Answer 4

I tend to lean toward ISO, but with file-naming limitations, the benefits of sorting, and yet still relatively human friendly, for your use case, I'd actually lean toward something like:

2020y01m14d_12h30m11s_8765ms-23hrs-UTC.log
2020y01m15d_12h31m11s_7654ms-23hrs-UTC.log
2020y01m16d_12h27m11s_9867ms-23hrs-UTC.log
2020y01m17d_12h41m11s_5432ms-23hrs-UTC.log
2020y01m18d_12h12m11s_6543ms-23hrs-UTC.log

Using lower-cased letters (a) reduces letter/number ambiguity for human consumers and (b) provides a bit of a better visual cue for the sections, while not messing up computers' ability to sort accurately.

The underscore is also simply for human consumers to help separate sets of information that tend to be consumed together.

Assumptions:

• all values have a consistently displayed width (e.g. every month value uses 2 characters)
• ALL entries would be in 23 hour values (otherwise typical file sorting wouldn't work consistently on hours). The 23hrs at the end is simply to remove any ambiguity about the matter.
• likewise ALL entries would be in UTC (because again, typical file sorting wouldn't work on hours of differing zones). The UTC at the end is again simply to remove any ambiguity about the matter.