F20 System Wide Change: No Default Syslog

[Nicolas Mailhot]

Le Mar 16 juillet 2013 18:42, Lennart Poettering a écrit :
> On Tue, 16.07.13 18:09, Till Maas (opensource at till.name) wrote:
>
>> On Tue, Jul 16, 2013 at 01:43:04PM +0200, Lennart Poettering wrote:
>> > On Tue, 16.07.13 09:42, Till Maas (opensource at till.name) wrote:
>> >
>> > > > journalctl only supports local time specifications when you
>> > > > specify calendar times. Unfortunately there's no nice API to map
>> > > > calendar times that include time zone specifications back to UTC,
>> in
>> > > > particular because the time zone names are not unique...
>> > > > While it will be hard to support arbitrary timezone specs in
>> --since= it
>> > > > should be relatively easy to support UTC in addition to the local
>> > > > timezone. Added this to the TODO list.
>> > >
>> > > You only need to add or subtract hours and minutes from the local
>> time,
>> > > because ISO 8601 dates contain the UTC offset:
>> > >
>> > > | $ date --iso-8601=seconds
>> > > | 2013-07-15T22:37:04+0200
>> >
>> > Well, we can certainly add support for such numeric timezone specs
>> > (added to the TODO list), but I have my doubts that this is actually
>> > what people want to use in their day-to-day use, given that the
>> numbers
>> > are hard to remember.
>>
>> Thank you.
>>
>> > I am pretty sure that most folks would like to specify symbolic
>> timezone
>> > names, but that's hard to do due to lack of APIs for that, and the
>> > non-uniqueness of the names.
>>
>> I guess for most use cases using the local time zone is enough.
>>
>> Btw. can journalctl output ISO 8601 dates instead of the US formated
>> date without a year? I really expected journalctl to cleanup this as
>> well.
>
> In the default output we stay true to the formatting that has been used
> in /var/log/messages since always.
>
> We currently do not use the ISO date format anywhere, it's not really
> readable, I think.

It's not really readable because you're not used to seeing it. You're not
used to seeing it because you (and others) have invented custom
alternatives. Seems a self-inflicted problem to me (just like most of the
"UTF-8 is too complex, it's simpler to use _pet-endoding_" were)

> Great way to serialize dates, recurring and duration
> events to ascii strings for computers to read, but not really for
> humans.
>
> Note that in all other places we tend to use date format like this: "Tue
> 2013-07-16 18:41:57 CEST" Which is close to ISO, but not ISO.

While replacing T with space is common (even though it will break field
tokenization in many apps) Tue is a pure Englicism (useless in most parts
of the world) and CEST will break interoperability (since people love to
invent new names for time zones. That's why the ISO numeric adjustment is
way saner).

Also "tend to" means "I'm not consistent and other apps and people can not
rely on any specific convention when dealing with me"

-- 
Nicolas Mailhot