Index | Thread | Search

From:
Martijn van Duren <openbsd+tech@list.imperialat.at>
Subject:
Re: syslogd: ISO8601 timestamp format in UTC by default
To:
Theo de Raadt <deraadt@openbsd.org>
Cc:
Rafael Sadowski <rafael@sizeofvoid.org>, tech@openbsd.org
Date:
Mon, 2 Nov 2026 18:55:00 +0100

Download raw body.

Thread
RFC3164 is network, and I am talking the network protocol. -Z doesn't
distinguish between files, or network; all targets get that time format.
Change the default? yes please. But why _force_ network incompatibility
by completely removing the old way?

On 11/2/26 17:58, Theo de Raadt wrote:
> I really don't give a damn when IETF starts telling us what content to
> place into FILES.  syslog files are not Internet.  That kind of interop
> is outside their mandate, and likely snuck onto the pages before most of
> you were born, likely to avoid the pages looking short and stark. This
> mandate-seeking does not come from IETF participants so it comes off as
> ridiciulous, and I reject it.  Having non-IETF participants expressing
> belief that IETF is an "authoritity" here is bizzare.  Defending such
> old words is simply indefensible.
> 
> Slightly on a tangent, IETF also is incapable of growing up and adapting
> to recognition the world needs something better, and when that
> recognition surfaces the IETF does they have *NO VIABLE PROCESS* to
> adapt.  Austin Group is somewhat similar (often rejects common practice,
> then argues in circles about modifying with incompatible behaviour
> before agreeing to it, or these days simply tries invent stuf noone will
> put into their OS). If IETF had been around when filenames were limited
> to 14 characters, someone could have considered that limitation a sign
> of purity, designed it into some aspect of some spec, and today we might
> have people who would flip that history into an belief that longer
> filenames are not IETF approved due some outdated RFC.  Oh the good old
> days when we considered those graybeards more than gods.  I don't. They
> operated with strong validity with that timeline, but times do change.
> 
> What use is a modern machine with huge disk space, available in more
> than 2 continents, if you can't store timezone insensitive, with
> accurate and increasingly precise timestamps?  I dunno.  Maybe that
> machine was intended to run some commercial operating system which
> widely ignores the little details in IETF standards?  Who hold us to
> a stronger silly standard?
>