thanks, this will be fixed in the next release already fixed and tested in the master source:
$ date +%K%z 196912310000.00 date: 196912310000.00: invalid date specification on parse, '#nnn' is interpreted as seconds since the epoch so this shows the UTC epoch $ date -u +%K%z '#0' 1970-01-01+00:00:00-0000 internally time is maintained as unsigned 64 bit nanoseconds since the epoch so the max date is $ date +%s.%N 2554-07-21+23:34:33.709551614-0000 18446744073.709551614 $ date -u +%K.%N%z '#18446744073.709551614' 2554-07-21+23:34:33.709551614-0000 and this may help the procrastinators among us: $ date -E now 'december 25' 6d00h -- Glenn Fowler -- AT&T Research, Florham Park NJ -- On Thu, 18 Dec 2008 20:27:49 -0800 (PST) bugzilla-daemon at np.grommit.com wrote: > Trying to reproduce a bug caused by VMWare having a broken TOD clock that > makes the system boot with time set to -1, I tried using the ksh93 date > builtin to set the time (after the Solaris /bin/date failed to do so), > but the ksh93 date builtin insists on sending me back to the future: > root at alf:~# date 196912310000.00 > > root at alf:~# date > > Sun Feb 21 21:41:31 PST 2010 > root at alf:~# date 197012310000.00 > > root at alf:~# date > > Thu Dec 31 00:00:01 PST 1970 > root at alf:~# ksh93 --version > > version sh (AT&T Research) 93t 2008-11-04 > root at alf:~# uname -a > > SunOS alf 5.11 snv_101 i86pc i386 i86pc > (I also tried date -e 0, thinking that would be close, but got "invalid date > specification" - guess -e is output format only, not input format.)
