On 2015-02-17 07:24, Denys Vlasenko wrote:
On Tue, Feb 17, 2015 at 5:52 AM, Rich Felker <dal...@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 <explore...@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@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@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))))."
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
