[PATCH] ls: no longer assume a 4-digit year on file timestamp.

Joshua Judson Rosen jrosen at harvestai.com
Tue Feb 17 23:27:51 UTC 2015


On 2015-02-17 07:24, Denys Vlasenko wrote:
> On Tue, Feb 17, 2015 at 5:52 AM, Rich Felker <dalias at libc.org> wrote:
>> On Mon, Feb 16, 2015 at 11:16:02PM -0500, Joshua Judson Rosen wrote:
>>> On 02/15/2015 06:06 AM, Steven Honeyman wrote:
>>>> On 15 February 2015 at 07:38, Explorer <explorer09 at gmail.com> wrote:
>>>>> This is a trivial change to allow a 5-digit-or-more year in 'ls' timestamp
>>>>> output.
>>>>>
>>>>> Signed-off-by: Kang-che Sung <explorer09-at-gmail.com>
>>>>
>>>> You realise we're good for almost 8000 more years? :D
>>>
>>> I guess it can already happen if your clock is grossly miscalibrated, though?
>>
>> Only on systems with 64-bit time_t. Otherwise years past 2038 don't
>> exist. :-)
>
> BTW:
>
> Current kernels internally use 64-bit nanosecond time,
> and they refuse to set date such that it overflows such counters.
> I failed to set date to year 2300. 2200 worked.

OTOH, I tried setting file-timestamps in the distant future and past
with (coreutils) "touch" command, and that worked just fine:

	jrosen at bz:~$ touch --date='+8000 years' tstamp; ls --full tstamp
	-rw-r--r-- 1 jrosen jrosen 0 10015-02-17 18:21:45.371567679 -0500 tstamp

	jrosen at bz:~$ touch --date='-8000 years' tstamp; ls --full tstamp
	-rw-r--r-- 1 jrosen jrosen 0 -5985-02-17 18:21:09.776568641 -0456 tstamp


I guess that leaves "user error" as a viable path....

-- 
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."


More information about the busybox mailing list