bug#40220: date command set linux epoch time failed

[Bob Proulx]

Paul Eggert wrote:
> Bob Proulx wrote:
> > By reading the documentation for CLOCK_MONOTONIC in clock_gettime(2):
> 
> GNU 'date' doesn't use CLOCK_MONOTONIC, so why is CLOCK_MONOTONIC relevant
> to this bug report?

GNU date uses clock_settime() and settimeofday() on my Debian system.
Let me repeat the strace snippet from my previous message which shows this.

  TZ=UTC strace -o /tmp/out -v date -s "1970-01-01 00:00:00"

  ...
  clock_settime(CLOCK_REALTIME, {tv_sec=0, tv_nsec=0}) = -1 EINVAL (Invalid 
argument)
  settimeofday({tv_sec=0, tv_usec=0}, NULL) = -1 EINVAL (Invalid argument)
  ...

Both calls from GNU date are returning EINVAL.  Those are Linux kernel
system calls.  Those Linux kernel system calls are using
CLOCK_MONOTONIC.  Therefore GNU date, on Linux systems, is by
association with the Linux kernel, using CLOCK_MONOTONIC.

And the Linux kernel is returning EINVAL.  And according to the
documentation for both clock_settime() and settimeofday() the most
likely reason for the EINVAL is the application of CLOCK_MONOTONIC
preventing it, because that documentation says that one cannot set the
date earlier than the system uptime.  Why this is desirable I have no
idea as it does not seem desirable to me.  But I am just the
messenger, having read that in the documentation looking for the
reason for the EINVAL return.

> Is this some busybox thing? If so, user 'shy' needs to report it to the
> busybox people, not to bug-coreutils.

No.  It is only a busybox thing as much as it is a GNU date thing in
that both are making system calls to the Linux kernel and both are
failing with EINVAL.  The reference to busybox confused me at first
too.  But in the original report it was simply another case of the
same thing.  Which is actually a strong indication that it is not a
bug in either of the frontend implementations but something common to
both.  In this case the kernel is the common part.

This does not appear to be a bug in the sense that it is explicit
behavior.  It is working as the Linux kernel has coded it to behave.
According to the documentation.

If one were to take this anywhere it would be to the Linux kernel
mailing list to discover why they implemented this inconvenient
behavior.

Meanwhile...  Since I am writing this in this thread...  I might
mention to the original poster that if they are testing using old
clock times they might be able to get a good result by using
libfaketime https://github.com/wolfcw/libfaketime which is a user land
strategy for implementing different fake clock times for programs.
Very useful in testing.  And then there would be no need to set the
system time at all.

  $ faketime '1970-01-01 00:00:00 UTC' date -uR
  Thu, 01 Jan 1970 00:00:00 +0000

Bob