From: Mike Eisler (mre@jurassic.eng.sun.com)
Date: 03/17/97-11:30:36 AM Z
Date: Mon, 17 Mar 1997 09:30:36 -0800 (PST)
From: Mike Eisler <mre@jurassic.eng.sun.com>
Subject: 1/1/1970
Message-ID: <Roam 0.9.4.858619836.19083.mre@jurassic.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
This archive was generated by hypermail 2.1.2 : 03/04/05-01:45:32 AM Z CST