From: Brent Callaghan (brent@caribe-86)
Date: 03/17/97-03:57:22 PM Z
Date: Mon, 17 Mar 1997 13:57:22 -0800
From: brent@caribe-86 (Brent Callaghan)
Message-Id: <199703172157.NAA09052@terra.eng.sun.com>
Subject: 1/1/1970
I don't think anyone has ever complained about NFS not supporting
dates prior to 1970, though perhaps that's just an artifact of
NFS' association with Unix and the inability of Unix to represent
those dates. I'd assume that these archival files would be filed
with names corresponding to dates for ease of retrieval.
The year 2106 sounds like an awfully long way off, though I guess
the year 2000 also did when I started my career in software engineering
and now the "Y2k" problem looms ominously. However, I'd hope that
by then our grandkids are as amused by V4 as we are by smoke signals.
Surely NFS v5 or even NFS v6 might then be widely deployed.
If we support 64 bit seconds values, then it'll add another 32 bits
to each of creation time, modification time, and last access time
attributes. For the next 109 years these extra bits will be zero
for the most part (except for files created prior to 1970).
So I wonder whether it's worth bulking out the current timestamps
in anticipation of a problem thats > 100 years hence.
BTW: CIFS SMB/CIFS supports three different time formats. The first
can describe dates up to 2099, the second is an unsigned 32 bit value
with a 1/1/1970 base (same as NFS seconds) and the third is a signed
64 bit value with an epoch of 1/1/1601 and 100 ns units.
Brent
----- Begin Included Message -----
>From mre Mon Mar 17 09:32:16 1997
Subject: 1/1/1970
To: "V.Rajendran" <rajen@calculus.distinct.com>
cc: nfs4-wg@sunroof.eng.sun.com
> As an aside, will 1st Jan 1970 be sacred ?
What problems have you encountered with using 1/1/1970 as a the basis for time?
One has define the base time to mean something. At least there are
non-proprietary references for the basis 1/1/1970.
I think we might want to address whether 32 bits of seconds is enough.
In the UNIX world, time is measured in seconds from 1/1/1970, and it is
typically kept as a signed 31 bit quantity ... thus time runs out in 2038. NFS
V2 and V3 use a 32 bit unsigned quantity, so time runs out on NFS in 2106.
Should an IETF filing protocol run out of time in our grand kids lifetime?
Professionalism would argue otherwise. Should the protocol account for files
that are whatever reason, might have timestamps < 1970? Consider the example
of some geology application that decides to use the O/S to stamp dates so that
files that map to historical events can be easily sorted. Flexibility would
argue that times < 1970 should be supported.
So I propose nfstime4:
struct nfstime4 {
int64 seconds;
uint32 nseconds;
};
Negative values of seconds are < 1970. This is more than adequate to
express dates within the theoretical lifetime of the universe.
-mre
----- End Included Message -----
This archive was generated by hypermail 2.1.2 : 03/04/05-01:45:32 AM Z CST