This is related, but I believe not a duplicate, of "Why cannot I set the date of my GNU/Linux machines to the Epoch?".

I've discovered that one of my Linux kernels rejects attempts to set the clock to a time during the first six minutes past the epoch:

root@beaglebone:/# date 010100061970
date: cannot set date: Invalid argument
Thu 01 Jan 1970 12:06:00 AM UTC
root@beaglebone:/# date 010100071970
Thu 01 Jan 1970 12:07:00 AM UTC

But seven minutes past the epoch works fine.

Anybody have any idea why this might be? When I have a chance I'll check the kernel sources for clues.

(No, it's not a practical question, just curiosity, and therefore perhaps more suited to retrocomputing.se or something. My attempt to set the clock in this way was in error, and the kernel did me a favor by rejecting it. But, still, it's odd.)

I know from other evidence that the rejection is not happening in the date command, but in the kernel itself. The settimeofday syscall is returning -1, with errno set to EINVAL.

This was on a Debian 10 system running kernel 4.19.94-ti-r42.

I also tried it on a Debian 11 machine, kernel 5.10.179-1, and it behaved similarly, although the "forbidden region" was two whole months at the beginning of 1970 — I couldn't seem to set a date earlier than March 1.

Update: Not only has the question now been answered, but the weird little side mystery is also resolved, namely why different machines I tested it on had different behavior. The first machine I tested it on had just recently been rebooted, and it wouldn't let me set the time to a value less than seven minutes past the epoch. But the second machine had been up for a couple of months, and it wouldn't let me set the time to a date earlier than March — that is, not within the first two months past the epoch. But that makes sense, because one way of stating the constraint is that you can't have (time since 1970) being less than (time since boot).

  • 4
    The UK used daylight saving time all year round for several consecutive years around 1970. So 01-Jan-1970 00:00:00 is actually -3600 seconds. Commented May 30 at 17:26
  • 6
    @Paul_Pedant That's a cute bit of trivia, but irrelevant, as the kernel deals in its version of UTC, with any local timezone subtracted out. 1970-01-01T00:00:00 is most definitely 0 seconds on the Unix clock, and I've confirmed that the problem occurs when small but positive values are passed to settimeofday. Commented May 30 at 17:43
  • 1
    So, if CLOCK_MONOTONIC corresponds to uptime, it should be easy to go from "may be doing" to "is likely doing" by comparing the observed limit against the system uptime? There's a comment saying essentially the same under the linked question too. Could it be as simple as guarding against someone getting a negative time if they try to find out when the system booted up?
    – ilkkachu
    Commented May 30 at 19:27
  • 1
    @ilkkachu Yup, that's more or less the experiment I hadn't had time to pursue yet. And it appears, per Joseph Sible's answer and the linked commit, that your speculation about negative boot time is exactly correct. Commented May 30 at 21:21
  • 1
    On the UTC comment - UTC is timezone independent it is nearly GMT, The UK being on summer time is irrelevant as GMT does not change for summer time. What does change is that the UK changes to and from GMT and BST(GMT+1)
    – mmmmmm
    Commented May 31 at 17:24

1 Answer 1


This is caused by commit e1d7ba873555 ("time: Always make sure wall_to_monotonic isn't positive"). Per the commit message:

This patch fix the problem by prohibiting time from being set to a value which would cause a negative boot time. As a result one can't set the CLOCK_REALTIME time prior to (1970 + system uptime).


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .