RE: NFSv4 Suggest Seconds 64bit value

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: Boris Z. (boris@conley.com)
Date: 07/23/98-11:29:23 AM Z 

Message-ID: <01BDB61C.612A17D0.boris@conley.com>
From: "Boris Z." <boris@conley.com>
Subject: RE: NFSv4 Suggest Seconds 64bit value
Date: Thu, 23 Jul 1998 09:29:23 -0700

> Information collected:
> 
> NT/SMB epoch 1601AD 64bit   ?????? unit 100ns
> Acorn  epoch 1900AD 40bit unsigned unit 100ns
> UNIX   epoch 1970AD 32bit   signed unit seconds and 32bit unit ns ie
> 1902 to 2038
> VMS    epoch 1858AD ??bit ?????? unit 100ns
> NFS    epoch 1970AD 32bit UNsigned unit seconds and 32bit unit ns
> 
> It is a good point *not* to assume the planet is earth.
> 
> It looks like 
> 
>    struct nfstime4 {
>        uint64_t seconds; /* Runs out ??????? */
>        uint32_t nseconds;
>    };
> WINS
> However the starting date looks like it needs to be 1600AD
> 
Damon,

I support your position that protocol should not restrict any homogeneous
interactions (NT to NT should not loose date range or precision). Looking forward for
future OS I think we need to adopt something like
struct nfstime4 {
	int64_t seconds; //**** signed
	uint32_t nseconds;
}
select the NFSv4 epoch on jan,1 0000 00:00:00.000000000 and allow negative
values to denote BC time.

boris

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-01:46:01 AM Z CST