Gregory Stark <[EMAIL PROTECTED]> writes: > "Tom Lane" <[EMAIL PROTECTED]> writes: >> I don't think it's an acceptable change in either place. People who >> want to see UTC in their logs can start the postmaster in UTC. Those >> who are accustomed to seeing local time will squawk.
> It would probably make sense to use UTC in the CSV logs since they're intended > to be machine readable. Whatever program is used to read them can handle > displaying the timestamps in the appropriate timezone for user's consumption. I don't think we really want to pay for formatting the timestamp twice (the existing patch goes out of its way to avoid that IIRC). Thinking back, the major reason why we use platform strftime() here is to ensure that all backends will print log entries in the same timezone regardless of session settings of the TimeZone GUC. That decision was taken a long time ago, before we had the modern GUC infrastructure, and also before we had pgtz infrastructure that could efficiently handle conversions in multiple zones at once. Perhaps it would make sense to invent a system-wide (PGC_SIGHUP) variable "log_timezone" and use pg_strftime() with that setting to format timestamps for the log. That would eliminate platform variability of all kinds, not just the immediate Windows issue, and it might gain performance on some platforms (glibc in particular has a bad habit of doing a syscall for every strftime call). The only downside I can think of is that problems with the log_timezone setting could lead to recursive errors and eventual PANIC, but that's true of almost anything that goes wrong during error printout. Comments? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org