F20 System Wide Change: No Default Syslog

[Till Maas]

On Mon, Jul 15, 2013 at 08:18:34PM +0200, Lennart Poettering wrote:

> > But there seems to be the problem that journalctl does not support
> > timezones/UTC time for since/until according to journalctl(1), therefore
> > there does not seem to be a safe way to specify since/until that will
> > even work when the current local UTC offset changes (daylight saving
> > time). Also it is sad that journalctl does not directly accept ISO 8601
> > time specifications (I can open a bug if there is a changes it will be
> > implemented).
> 
> glibc is actually smart enough to determine DST from the specified time
> itself (of course, this might guess incorrectly since during the switch
> there might be times that happen 'twice'), so this should be a
> non-issue.

Why is it a non-issue? It exactly breaks above code when the same local
time occurs twice during the switch.
Here are corresponding times for two UTC offsets during the switch:
2013-10-27 1:30+0200 2013-10-27 0:30+0100
2013-10-27 2:25+0200 2013-10-27 1:25+0100
2013-10-27 3:20+0200 2013-10-27 2:20+0100
2013-10-27 4:15+0200 2013-10-27 3:15+0100

You will get these calls
--since 1:30 --until 2:25 (UTC+2) normal report
--since 2:25 --until 2:20 (UTC+1) no report
--since 2:20 --until 3:15 (UTC+1) partly duplicate report, 1 hour
delayed

> 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


> Note that the journal actually knows a concept called "cursors". The
> cursors are a way to refer to a specific log line (or the closest
> available one) in a stable way. by using this you can make a logic like
> the above work nicely, and even remove any inaccuracy regarding
> timestamps...

The manpage only mentions how to specify which cursor to use but not how
to get the cursor of the last read line.

Regards
Till