Date: Tue, 30 Oct 2001 11:02:42 -0700 From: Nate Williams <nate@yogotech.com> To: Julian Elischer <julian@elischer.org> Cc: Peter Wemm <peter@wemm.org>, Bruce Evans <bde@zeta.org.au>, Garance A Drosihn <drosih@rpi.edu>, Nate Williams <nate@yogotech.com>, arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <15326.60226.510153.799277@caddis.yogotech.com> In-Reply-To: <Pine.BSF.4.21.0110300949340.26174-100000@InterJet.elischer.org> References: <20011030173210.59A5F39F4@overcee.netplex.com.au> <Pine.BSF.4.21.0110300949340.26174-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > ... UFS does not have future dates ... > > > > > > Script started on Tue Oct 30 21:04:39 2001 > > > ttyv7:bde@delplex:/tmp> touch -t 203801011230 foo > > > ttyv7:bde@delplex:/tmp> ls -l foo > > > -rw-r--r-- 1 bde wheel 0 Jan 1 2038 foo > > > ttyv7:bde@delplex:/tmp> exit > > > > I know that.. This is a contrived example. atime, mtime, ctime are defined > > as the time that the file was last operated on. One does not do 30-year > > mortgage calculations using ufs file timestamps. The only dates they *need* > > to support is "a long time ago" through "now". > > > One added note however.. I am expecting that there will be embedded > systems being deployed NOW that will be in service in 2038. If there are, and they rely on the timestamps on the filestamps, the developers must be aware of the current limitations of the timestamps on the FS. I think most folks are aware of these kinds of issues after the entire Y2K fiasco. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15326.60226.510153.799277>