On Sun, 23.03.14 11:06, Dave Reisner (dreis...@archlinux.org) wrote:
> Also adds a few tests for the absolute cases of parse_timestamp.
>
> Suggested by: Mantas Mikulėnas <graw...@gmail.com>
> ---
> src/shared/time-util.c | 10 ++++++++++
> src/test/test-time.c | 21 +++++++++++++++++++++
> 2 files changed, 31 insertions(+)
>
> diff --git a/src/shared/time-util.c b/src/shared/time-util.c
> index faa3418..fe43404 100644
> --- a/src/shared/time-util.c
> +++ b/src/shared/time-util.c
> @@ -432,6 +432,7 @@ int parse_timestamp(const char *t, usec_t *usec) {
> * tomorrow (time is set to 00:00:00)
> * +5min
> * -5days
> + * @1395584178 (seconds from the epoch)
> *
> */
>
> @@ -473,7 +474,16 @@ int parse_timestamp(const char *t, usec_t *usec) {
> return r;
>
> goto finish;
> + } else if (t[0] == '@') {
> + time_t epoch;
>
> + r = safe_atoli(t+1, &epoch);
> + if (r < 0)
> + return r;
> +
> + assert_se(localtime_r(&epoch, &tm));
> +
> + goto finish;
Hmm, this is probably something we should return directly without
involving "finish"... After all it's kinda pointless to convert these
epoch times to calendar times first, and then back again... We should
just return them directly.
also, wouldn't it be more appropriate to use parse_sec() for pasing
this? That would also allow the syntaxes "@30years" referrring 30 years
after the epoch and similar. Not that this would be super-useful, but at
least it would correspond nicely with the "+5min" and "-5min" syntaxes
we already have, which do use parse_sec()...
Lennart
--
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
