Path: utzoo!attcan!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!scs
From: scs@athena.mit.edu (Steve Summit)
Newsgroups: comp.std.c
Subject: Re: The type of time_t (was: struct tm -> time_t converter wanted)
Message-ID: <7917@bloom-beacon.MIT.EDU>
Date: 12 Nov 88 07:25:08 GMT
References: <442@grand.UUCP> <8700@smoke.BRL.MIL> <6964@cdis-1.uucp> <9816@haddock.ima.isc.com> <1988Oct22.230215.19411@utzoo.uucp> <26582@ucbvax.BERKELEY.EDU> <8810281846.AA20611@champlain.dgp.toronto.edu>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Lines: 18

In article <8810281846.AA20611@champlain.dgp.toronto.edu> flaps@dgp.toronto.edu (Alan J Rosenthal) writes:
>So any zero-date in the past
>is ok, because a file need not be able to have a timestamp predating the
>writing of the operating system it is available on.

This is, I'll admit, a nit, but I'd suggest otherwise.  I pay a
lot of attention to file modification times, and I often transfer
files between different operating systems (Unix, VMS, MS-DOS)
while attempting to preserve modification times (using tar and
the like).  This means that I have a problem if I take a file
last modified in 1979 to an MS-DOS system, because DOS's epoch is
1980.  (The problem is theoretically even worse when moving files
from VMS, which has an epoch of 1865 or so.)  Not much of a
problem in practice, but it's something to think about.  (And, of
course, it's insoluble.)

                                            Steve Summit
                                            scs@adam.pika.mit.edu