Repository navigation
DateLayoutRenderer default Format should be culture invariant #6232
Description
Little weird that DateLayoutRenderer has the default Format:
yyyy/MM/dd HH:mm:ss.fff
Why not follow the default-format found every where else in NLog:
yyyy-MM-dd HH:mm:ss.ffff
Interesting that ${date} "originally" was born with default Format = G, that would follow the local culture. Then later hard-coded to one culture with explicit Format-string (with ffff). Think that Logging library should stay culture invariant unless requested otherwise.
Also $[processtime} should match the following format (Instead of fff):
HH:mm:ss.ffff
Activity
[-]DateLayoutRenderer should change default Format[/-][+]DateLayoutRenderer should have culture invariant default Format[/+][-]DateLayoutRenderer should have culture invariant default Format[/-][+]DateLayoutRenderer Format should be culture invariant[/+][-]DateLayoutRenderer Format should be culture invariant[/-][+]DateLayoutRenderer default Format should be culture invariant[/+]HarnageaGabriel commentedon Aug 18, 2026
Hi @snakefoot, looking into this one.
Investigating
DateLayoutRendererondev, I see theCultureproperty already defaults toCultureInfo.InvariantCulture(set inDateLayoutRenderer.csvia #5740, merged 2025-03-23), andGetFormatProvideralways prefers that non-null layout-level culture overlogEvent.FormatProvider/DefaultCultureInfo. So with today'sdevcode, the default${date}output is already culture-invariant in the sense that it won't change with the thread/system culture — the/and:literals in the format string resolve to invariant separators regardless of environment.So the concrete remaining gap looks like it's the default
Formatstring itself:yyyy/MM/dd HH:mm:ss.fffvs. the convention used elsewhere in NLog (${longdate},InternalLogger) ofyyyy-MM-dd HH:mm:ss.ffff. Changing that default text is a visible output change for anyone using${date}without an explicitFormat, which is presumably why this is taggedbreaking change/breaking behavior change.Before I write the fix, which direction do you want:
(a) Straight default change — flip the default
Formattoyyyy-MM-dd HH:mm:ss.ffffto match the rest of NLog. Breaking, would need a major version bump.(b) Opt-in — keep today's default
Formatstring as-is, and add an opt-in way to get the invariant/ffffconvention (e.g. a configurable flag or documented alternate format) without touching existing behavior for current users.(c) Something else you have in mind — including whether
ProcessTimeLayoutRenderer'sfff→ffffmention should be split into its own issue.If I don't hear back in a bit I'll go with (b) as the safer non-breaking default, and note (a) as an easy follow-up if you'd rather take the breaking route.
snakefoot commentedon Aug 18, 2026
The milestone is for NLog v7 (milestone). I just have a bad memory, so I use Github-issue to remember my observations.
There is no bug, it is just a funny default value, so people who needs different Format can just assign a different value (already working).
See also #6235 for other NLog v7 related ideas that I'm thinking about. There is no NLog v7 roadmap or deadline, so mostly for the todo-list.
DateLayoutRenderer - Changed default Format to yyyy-MM-dd HH:mm:ss.ffff