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