On Tue, Jul 16, 2013 at 01:43:04PM +0200, Lennart Poettering wrote:
On Tue, 16.07.13 09:42, Till Maas (opensource@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.
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.
journalctl -o verbose will give you that (and so will -o json, -o export and others), but the rest of the output is very low-level then. Maybe we can add a switch that prints the final cursor as last line if you specify some switch.
The extra switch sounds useful.
Regards Till