On 2026-08-14, Mike <[email protected]> wrote: > > > On 8/13/2026 11:52 PM, Mike wrote: >> >> >> On 8/13/2026 10:25 PM, Mike wrote: >>> >>> >>> On 8/13/2026 9:48 PM, Mike wrote: >>> >>> Apologies, I should have also provided... >>> >>> OpenBSD 7.9 AMD64. >>> >>> And the default syslog-ng.conf file. >>> >> >> At this point I am considering just staying with my patches to the >> OpenBSD syslogd to get the time format I prefer. >> >> But, please allow me to ask a question ... >> >> If I were to submit a patch to syslogd to allow the ISO format in local >> time, is that something that might be looked at? >> >> Maybe, instead of in rc.conf.local ... >> >> syslogd_flags=-Z >> >> there might be an option >> >> syslogd_flags=-L >> >> >> Submitting patches is not a new thing for me (please see ntpctl). >> >> But I do have to say, I am getting old and my c coding skills are waning... >> >> But, I'll try to rally for this ... >> >> > > fwiw, > the current patch file I use is:
I do think that patched OpenBSD syslogd is probably more likely what I'd do if I needed this. >============== > > --- syslogd.c.orig Thu Jun 26 15:10:13 2025 > +++ syslogd.c Sat May 30 17:41:22 2026 > @@ -1788,13 +1788,13 @@ > struct tm *tm; > size_t l; > > - tm = gmtime(&now.tv_sec); > + tm = localtime(&now.tv_sec); > l = strftime(timestamp, 33, "%FT%T", tm); > /* > * Use only millisecond precision as some time has > * passed since syslog(3) was called. > */ > - snprintf(timestamp + l, 33 - l, ".%03ldZ", now.tv_usec / 1000); > + snprintf(timestamp + l, 33 - l, ".%03ld", now.tv_usec / 1000); while you can change it in whichever you want locally, I think I'd object to committing a change which did it this way, i.e. without also logging the UTC offset. if you're trying to use those logs for incident response, especially across a DST change (though also if /etc/localtime is changed on a system), it's a bit of a problem to lose that information. > } else > strlcpy(timestamp, ctime(&now.tv_sec) + 4, 16); > } > > >=================== > > > But I do understand that changes would need to be made beyond that patch > file. Options parsing, man descriptions, etc .... > > I'll try ... that's pretty straightforward tbh.
