coreutils-5.2.1, touch, and 64-bit time-of-day clocks

[Nelson H. F. Beebe]

While preparing examples of using the touch command to create files
with user-specified timestamps, I found an apparent bug in touch from
coreutils-5.2.1 (and presumably, earlier versions) that is evident on
systems that have a 64-bit time-of-day clock.  Among the 20+ flavors
of Unix that I have access to, only two systems, DEC Alpha GNU/Linux
and HP/Intel/Dell Itanium-2 GNU/Linux, have such clocks.  Compaq/DEC
Alpha with OSF/1 4.0 or 5.1 does not support more than a 32-bit clock.

I found that these three work:

        % touch -t 000001010000.00 /tmp/foo ; ls -l /tmp/foo
        -rw-rw-r--  1 beebe wheel 0 0-01-01 00:00 /tmp/foo

        % touch -t 178907140000.00 /tmp/first-Bastille-day
        % ls -l /tmp/first-Bastille-day
        -rw-rw-r--  1 beebe wheel 0 1789-07-14 00:00 /tmp/first-Bastille-day

        % touch -t 999912312359.59 /tmp/end-of-9999
        % ls -l /tmp/end-of-9999
        -rw-rw-r--  1 beebe wheel 0 9999-12-31 23:59 /tmp/end-of-9999

However, this fails:

        % touch -t 1000001010000.00 /tmp/start-of-10000
        touch: invalid date format `1000001010000.00'

A 64-bit clock at 1-second resolution has a period of 584,942,417,355
years; even at microsecond resolution, the period is still 584,942
years.

It looks to me like the "invalid date format" diagnostic is simply an
artificial restriction on the argument of touch that should be
removed in the next release of coreutils.

To test this further, I wrote this program:

% cat settime.c
/***********************************************************************
Experiment with 64-bit time-of-day clocks.

Usage:
        settime time_t_value filepath

The default time_t_value is 0xffffffffffffffffUL, and the default
filepath is "/tmp/foo".

[02-Apr-2004]
***********************************************************************/

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/time.h>
#include <utime.h>

int
main(int argc, char* argv[])
{
    unsigned long long t;
    struct utimbuf u;
    const char *path;

    t = (argv[1] == (char *)NULL) ? 0xffffffffffffffffUL :
                                    (unsigned long long)strtoull(argv[1], 
(char**)NULL, 0);
    path = (argv[2] == (char *)NULL) ? "/tmp/foo" : argv[2];

    u.actime = (time_t)t;
    u.modtime = (time_t)t;

    utime("/tmp/foo", &u);

    return (EXIT_SUCCESS);
}

Here are some runs on an Itanium-2 system:

        % ./settime 0x7fffffff /tmp/foo ; ls -l foo
        -rw-rw-r--  1 beebe wheel 0 2038-01-18 20:14 foo

        % ./settime 0xffffffff /tmp/foo ; ls -l foo
        -rw-rw-r--  1 beebe wheel 0 2106-02-06 23:28 foo

        % ./settime 0xfffffffff /tmp/foo ; ls -l foo
        -rw-rw-r--  1 beebe wheel 0 4147-08-20 00:32 foo

        % ./settime 0xffffffffff /tmp/foo ; ls -l foo
        -rw-rw-r--  1 beebe wheel 0 36812-02-19 17:36 foo

        % ./settime 0xfffffffffff /tmp/foo ; ls -l foo
        -rw-rw-r--  1 beebe wheel 0 559444-03-08 02:40 foo

        % ./settime 0xffffffffffff /tmp/foo ; ls -l foo
        -rw-rw-r--  1 beebe wheel 0 8921556-12-07 03:44 foo

        % ./settime 0xfffffffffffff /tmp/foo ; ls -l foo
        -rw-rw-r--  1 beebe wheel 0 142715360-12-05 20:48 foo

        % ./settime 0xffffffffffffff /tmp/foo ; ls -l foo
        -rw-rw-r--  1 beebe wheel 0 72057594037927935 foo

        % ./settime 0xfffffffffffffff /tmp/foo ; ls -l foo
        -rw-rw-r--  1 beebe wheel 0 1152921504606846975 foo

        % ./settime 0x7fffffffffffffff /tmp/foo ; ls -l foo
        -rw-rw-r--  1 beebe wheel 0 9223372036854775807 foo

        % ./settime 0x8000000000000000 /tmp/foo ; ls -l foo
        -rw-rw-r--  1 beebe wheel 0 -9223372036854775808 foo

        % ./settime 0xffffffffffffffff /tmp/foo ; ls -l foo
        -rw-rw-r--  1 beebe wheel 0 1969-12-31 16:59 foo

Clearly, the largest positive time supported is 0x7fffffffffffffff,
which ls reports as 9223372036854775807; that is exactly 2^(63) - 1.
It appears that ls stops reporting years somewhere after
0xfffffffffffff (= 2^(52) - 1), and switches to seconds.  One can
debate whether that is a feature or a bug.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: address@hidden  -
- 155 S 1400 E RM 233                       address@hidden  address@hidden -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe  -
-------------------------------------------------------------------------------