Hi Ben,
thanks for reporting this. Please be advised that a newer release is
available upstream, which however likely is not related to your issue.
With your calls, you should not use the '-f' parameter. Without '-f',
the timestamp is passed on to date/gdate for parsing, which yields the
following for me on Debian Buster x86_64:
./faketime '2019-09-06 03:14:37 02:00' /bin/date
date: invalid date ‘2019-09-06 03:14:37 02:00’
Error: Timestamp to fake not recognized, please re-try with a different
timestamp.
./faketime '2019-09-06T03:14:37+02:00' /bin/date
Fri 06 Sep 2019 03:14:37 AM CEST
So the "iso-strict" variant seems to work out of the box.
When using '-f', the specified string is directly passed on to
libfaketime by the 'faketime' wrapper without parsing (using
date/gdate). In this case, you either have to stick to one of the
formats that libfaketime expects (as documented in the README at
https://github.com/wolfcw/libfaketime), or, which might be more
appropriate for your case, you also have to set the FAKETIME_FMT
environment variable.
I hope that helps a bit.
I also agree that "Success" isn't much of a useful error message here.
In this case, it's created by a call to the standard perror() system
call, which should be considered to be replaced with something more
meaningful. I'll put that on the todo list. :-) However, more useful
error messages are printed by the wrapper when '-f' is not used.
Best regards
Wolfgang
Ben Wiederhake wrote on 08.09.19 20:54:
Package: faketime
Version: 0.9.7-3
Severity: normal
Dear Maintainer,
I've tried to use faketime to build something reproducibly, by using the git
commit time.
Git offers shortcuts for the formats "iso" (e.g. "2019-09-06 03:14:37 +0200")
and "iso-strict" (e.g. "2019-09-06T03:14:37+02:00").
Steps to reproduce, and actual behavior in bash:
$ LC_ALL=C faketime -f "2019-09-06 03:14:37 02:00" true # "iso"
[$? = 0]
$ LC_ALL=C faketime -f "2019-09-06T03:14:37+02:00" true # "iso-strict"
Failed to parse FAKETIME timestamp: Success
[$? = 1]
Expected behavior: Either the second invocation should "just work",
or produce a more meaningful error message.
I prefer the first behavior, and "Success"
sounds like the parsing actually worked, just got handled wrongly,
so maybe this can be done easily?
For my little thing I'll just use git's "iso" shortcut.
Cheers,
Ben Wiederhake
-- System Information:
Debian Release: bullseye/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8),
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages faketime depends on:
ii libc6 2.28-10
ii libfaketime 0.9.7-3
faketime recommends no packages.
faketime suggests no packages.
-- no debconf information
