Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!gvlf3.gvl.unisys.com!faatcrl!jprad
From: jprad@faatcrl.UUCP (Jack Radigan)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: JR-Comm v1.02 download date bug
Message-ID: <1523@faatcrl.UUCP>
Date: 30 Jun 91 15:10:50 GMT
References: <clemon.4794@lemsys.UUCP> <1491@faatcrl.UUCP> <clemon.4978@lemsys.UUCP>
Organization: FAA Technical Center, Atlantic City NJ
Lines: 32

clemon@lemsys.UUCP (Craig Lemon) writes:

>        Well, today (see header date) it showed that all the files I
>downloaded were created on Jul 12, 1983.  When I took a close look at my dl
>directory, Quite a few of them were.  I fixed todays files by resetting the
>datestamp.

>        Could you elaborate on your comment about "some systems send brain
>damaged datestamps".  My machine is at fault?  It never did this before
>until v1.02.  Also, GMT+13 = EDT (EST whatever)?  How will that fix a date
>reading 1983?

  Actually, before 1.02, the datestamp function was partially broke.  It wasn't
modifying the date on certain devices properly, so the local creation date was
always used, not the ZMODEM supplied datestamp from the transfer.

  The ZMODEM datestamp is in octal, and represents the UNIX beginning of
time in seconds from 1/1/72, which has to be changed to the Amiga's 1/1/78 idea
of time.  Also, the timezone is taken into account with the sender subtracting
GMT and the receiver adding GMT offsets so that the datestamp reflects the real
time that it was created.

  Some systems, or I should say, some versions of ZMODEM screw the datestamp
to hell.  Now that JR-Comm is handling all datestamps properly, we're seeing
really weird dates come up.  So, what I did was add a GMT 13 which doesn't
exist.  If JR-Comm is set to that value, it will bypass the function that
modifies the datestamp to the recieved time so that only the created date is
used.

  Hope this clears it up some.

  -jack-