Add year, minute to the --diagnostic filename

[AliveDevil]

Describe the bug

The --diagnostic-option creates files with an opaque, non-modified date sorting friendly file name.

Steps To Reproduce

1. Run multiple successive tests with --diagnostic, when process Ids are recycled, the name sorting option is useless.

Expected behavior

Some name sorting friendly file prefix (i.e. log_yyyymmddThhmmss_ProcessId.diag).

Actual behavior

log_09030958760.diag: 11:47
log_09031011248.diag: 12:30
log_09031028245.diag: 12:34
log_09031043246.diag: 12:17
log_09031043969.diag: 12:10
log_09031045242.diag: 12:34
log_09031055355.diag: 12:09

[nohwnd]

Adding to next milestone, looks like low hanging fruit, and I don't think change of name in diag log should be considered a breaking change.

[MarcoRossignoli]

? Some name sorting friendly file prefix (i.e. log_yyyymmddThhmmss_ProcessId.diag)

Fine to me a format like that, keeping in mind that you should not take the "process_id" as guarantee for nothing, that id can be reused for different processes, maybe we can simply have time ordering, anyway today we have a retry loop if the file is already taken by someone else in the same folder so the order will be preserved and the pid says nothing about the nature of the file, maybe we can add the tfm the make easy to read it.

[MarcoRossignoli]

@AliveDevil I did a check of the code and we're creating the file with the pattern

$"{_options.LogPrefixName}_{_clock.UtcNow.ToString("MMddHHssfff", CultureInfo.InvariantCulture)}.diag";

You can change the prefix using the option --diagnostic-output-fileprefix as explained here https://learn.microsoft.com/en-us/dotnet/core/testing/unit-testing-platform-intro?tabs=dotnetcli#options

Now the logs are already "ordered", it's not clear to me what's the difference if we change the file name pattern.

Can you elaborate why the current stable ordering is not enough? You'll have always the log files ordered and adding the PID doesn't change much, the time granularity is small enough to make it useless for ordering scope.

[AliveDevil]

When the format really is:

• Two Digit Month
• Two Digit Day
• Two Digit Hour
• Two Digit Seconds
• Three Digits Milliseconds

I'm missing a two digit minutes field there.

Thus a diagnostics log for 2024-30-09 01:00:59.000 is listed after a diagnostics log for 2024-30-09 01:59:00.000 which doesn't make sense and is unintuitive. Based on the format above:

• 09300100000 for the 58 minutes later 2024-30-09 01:59:00.000
• 09300159000 for the top-of-the-hour 2024-30-09 01:00:59.000

I thought it was the PID, because it was just random garbage which didn't end up making any sense when combined with the explorer reported date (and five digit process ids arent that uncommon).

[MarcoRossignoli]

Thus a diagnostics log for 2024-30-09 01:00:59.000 is listed after a diagnostics log for 2024-30-09 01:59:00.000 which doesn't make sense and is unintuitive. Based on the format above:

Ok now it's clear my bad, we can add back the minute(we wanted to have short name as possible), usually I don't expect users will parse the filename and the creation time should be used for the ordering(done by OS and preserved with the copy).