The type of time_t (was: struct tm -> time_t converter wanted)

[Lum Johnson]

In article <7917 at bloom-beacon.MIT.EDU> scs at adam.pika.mit.edu (Steve Summit) writes:
>In article <8810281846.AA20611 at champlain.dgp.toronto.edu> flaps at 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.
>
>... 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.)

Good point - this might be important or useful information.  The epoch you're
referring to is probably 0000 GMT 17-Nov-1858, the same as for pdp-10 monitors
with which I am familiar.  The date was chosen by someone at The Smithsonian
Institution if I recall correctly;  I no longer remember the significance, but
it was probably when the Gregorian calendar was adopted by some official group
or major government.

Our local EXEC has been modified to change the write date when a file is copied
so as to avoid the file migration policy.  This annoys me so much that I have
another version of the EXEC without this modification for my use.  (In fact, I
have several EXECs with and without various nasty "features".)
-=-
-- 
Lum Johnson    lum at osu-20.ircc.ohio-state.edu    lum at tut.cis.ohio-state.edu
"You got it kid -- the large print giveth and the small print taketh away."
-------