1

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

Improve this question
3
  • Why do you need 12of23H, 30of59M, 11of59S, and 8675of9999MS instead of 12H, 30M, 11S, and 8675MS?
    – Erhan Yaşar
    Dec 5, 2019 at 22:13
  • clocks say 12 twice a day. 12of23 lets someone new to the system know which 12 this is referring to
    – DaveAlger
    Dec 6, 2019 at 15:29
  • 2
    Like almost all of the companies in tech industy doesn't care of the poeple who can't even open a computer or a smart phone, you may consider your time in 24 hours and write it on the documentation where possible as let your users to understand since they also aware of it's ambiguity, therefore they can think of it should be in 24 hr.
    – Erhan Yaşar
    Dec 6, 2019 at 15:40

4 Answers 4

Reset to default
9

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.

Improve this answer
6
  • The colon(:) character is not allowed in filenames on Windows and there are issues displaying it on Macs, so should be avoided if the produced files are likely to be used on those platforms.
    – dosxuk
    Dec 6, 2019 at 11:36
  • @dosxuk Ah, I wasn't aware. Thanks for the tip; I've edited to include this note.
    – maxathousand
    Dec 6, 2019 at 14:14
  • so we come full circle to my initial solution of 201912051357040042.log as the file name and requiring new users to poke around when the hour is 12 (since it can equally be assumed midnight or noon)
    – DaveAlger
    Dec 6, 2019 at 15:34
  • Do you need to consider time zones as well? One person's 2007-04-05T14:30 is not necessarily everyone's, at least not simultaneously.
    – Mattynabib
    Dec 9, 2019 at 16:37
  • 1
    @Mattynabib Good point. The format does specify how to represent timezone information as well: Either suffix it with the appropriate offset, for example, with -06:00, or represent it in Coordinated Universal Time (UTC) and suffix with a Z to designate it as UTC time. To quote that Wikipedia article: "If a time zone designator is required, it follows the combined date and time. For example, "2007-04-05T14:30Z" or "2007-04-05T12:30-02:00"."
    – maxathousand
    Dec 9, 2019 at 16:46
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
Improve this answer
2
  • I considered doing 5DEC2019 because spelling out the month allows the user to deduce the big number as the year and the small number as the day but then the names won't sort chronologically which I think is important.
    – DaveAlger
    Dec 6, 2019 at 18:04
  • That's a really nice second option. I like the {machine readable}__{human readable} combination!
    – maxathousand
    Dec 12, 2019 at 13:35
1

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

Improve this answer
2
  • the second one is actually pretty easy to understand, should sort chronologically and I especially like how the letters both label and separate the numbers. nice work!
    – DaveAlger
    Dec 6, 2019 at 18:08
  • Glad it helped @DaveAlger!.. I'd be happier if you check that my answer helped if it's so..
    – Erhan Yaşar
    Dec 8, 2019 at 17:52
1

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.
Improve this answer

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.