ppkarwasz commented on issue #3161: URL: https://github.com/apache/logging-log4j2/issues/3161#issuecomment-3664391139
Yes, in `main` there are no longer any predefined date/time patterns. Based on real-world usage I have observed, most users tend to define their own preferred timestamp format. As a result, predefined patterns add maintenance cost without delivering much value, since they are rarely used as-is. One possible exception we might consider is [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339), which provides a well-defined, timezone-aware, and widely recognized format. It could serve as a reasonable and safe default. If we were to provide predefined options, I could imagine limiting them to a small, RFC 3339-based set, for example: * **RFC 3339 `date-time`**: suitable for generic log output * **RFC 3339 `full-date`**: useful for `filePattern` in rolling appenders * **RFC 3339 `full-time`**: potentially useful when the date is already encoded in the file name (assuming rolling appenders preserve it correctly) Rather than exposing these as implicit pattern shortcuts, I think it would be cleaner to define them as explicit Log4j plugins, similar to how the predefined color converters (`%black`, `%blue`, etc.) are implemented today. These plugins should probably default to UTC to avoid ambiguity. Beyond this, I don’t see much value in additional predefined patterns. In practice, they often lead to locale-specific or timezone-less timestamps, which make it difficult to debug issues, especially around DST transitions. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
