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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
