jessea@dynasys.UUCP (Jesse W. Asher) (11/10/90)
I was looking in the status files for UUCP connections and I was trying
to figure out what date was used to calculate the below number:
0 0 658135267 0 SUCCESSFUL rutgers
^^^^^^^^^
I assume that this is the date of the last connection. If this assumption
is incorrect, what is this number? If it is correct, I have a few more
questions. Why is such an old date used? Why not just use the beginning
of the year? And what is the date that is being used? Any ideas?
---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---
Jesse W. Asher Phone: (901)382-1609
6196-1 Macon Rd., Suite 200, Memphis, TN 38134
UUCP: {fedeva,chromc,rutgers}!dynasys!jessea
-> He who steps on others to reach the top has good balance.blm@6sceng.UUCP (Brian Matthews) (11/11/90)
In article <736@dynasys.UUCP> jessea@dynasys.UUCP (Jesse W. Asher) writes: |I was looking in the status files for UUCP connections and I was trying |to figure out what date was used to calculate the below number: | |0 0 658135267 0 SUCCESSFUL rutgers | ^^^^^^^^^ |I assume that this is the date of the last connection. Last attempt at connection actually. |If it is correct, why is such an old date used? Huh? It's Nov 8 23:21:07 1990, plus or minus time zone differences. Doesn't seem so old to me. -- Brian L. Matthews blm@6sceng.UUCP
bob@rscsys.UUCP (Bob Celmer) (11/11/90)
In article <736@dynasys.UUCP> jessea@dynasys.UUCP (Jesse W. Asher) writes: >I was looking in the status files for UUCP connections and I was trying >to figure out what date was used to calculate the below number: > >0 0 658135267 0 SUCCESSFUL rutgers > ^^^^^^^^^ > >I assume that this is the date of the last connection. If this assumption >is incorrect, what is this number? If it is correct, I have a few more >questions. Why is such an old date used? Why not just use the beginning >of the year? And what is the date that is being used? Any ideas? I believe that number represents the number of seconds that have elapsed during the UNIX epoch, deemed to have begun at Midnight GMT on 1 January, 1970. Try the following short piece of C code. #include <stdio.h> main() { long time(); long *tloc; long big_num; big_num = time(tloc); printf("\nSeconds since 1 Jan 1970: %ld\n",big_num); } -- Bob Celmer UUCP: {fedeva,chromc}!dynasys!rscsys!bob
pjh@mccc.uucp (Pete Holsberg) (11/13/90)
In article <554@6sceng.UUCP> blm@6sceng.UUCP (Brian Matthews) writes: =In article <736@dynasys.UUCP> jessea@dynasys.UUCP (Jesse W. Asher) writes: =| =|0 0 658135267 0 SUCCESSFUL rutgers =| ^^^^^^^^^ =|I assume that this is the date of the last connection. =Huh? It's Nov 8 23:21:07 1990, plus or minus time zone differences. Could you explain how you got Nov 8 23:21:07 1990 out of 658135267??? Thanks. Pete -- Prof. Peter J. Holsberg Mercer County Community College Voice: 609-586-4800 Engineering Technology, Computers and Math UUCP:...!princeton!mccc!pjh 1200 Old Trenton Road, Trenton, NJ 08690 Internet: pjh@mccc.edu Trenton Computer Festival -- 4/20-21/91
ardai@teda.UUCP (Mike Ardai) (11/14/90)
In article <1990Nov12.161416.20549@mccc.uucp> pjh@mccc.edu (Pete Holsberg) writes: -In article <554@6sceng.UUCP> blm@6sceng.UUCP (Brian Matthews) writes: -=In article <736@dynasys.UUCP> jessea@dynasys.UUCP (Jesse W. Asher) writes: -=|0 0 658135267 0 SUCCESSFUL rutgers -=| ^^^^^^^^^ -=Huh? It's Nov 8 23:21:07 1990, plus or minus time zone differences. -Could you explain how you got Nov 8 23:21:07 1990 out of 658135267??? Thanks. (We are running on Eastern Standard Time here) main() { long l = 658135267; puts(ctime(&l)); } Fri Nov 9 07:21:07 1990 -- \|/ Michael L. Ardai Teradyne EDA East --- ------------------------------------------------------------------------- /|\ ...!sun!teda!ardai (preferred) or ardai@bu-pub.bu.edu
gary@sci34hub.UUCP (Gary Heston) (11/14/90)
In article <736@dynasys.UUCP> jessea@dynasys.UUCP (Jesse W. Asher) writes:
=I was looking in the status files for UUCP connections and I was trying
=to figure out what date was used to calculate the below number:
=0 0 658135267 0 SUCCESSFUL rutgers
^^^^^^^^^
=I assume that this is the date of the last connection. If this assumption
=is incorrect, what is this number? If it is correct, I have a few more
=questions. Why is such an old date used? Why not just use the beginning
The date is the internal format, which is defined as the number of seconds
since January 1, 1970. (Reportedly day 0, year 0, of the age of Unix.)
All Unix dates are maintained in this format, for some reason; in things
like ls you see a converted date.
--
Gary Heston System Mismanager and technoflunky uunet!sci34hub!gary or
My opinions, not theirs. SCI Systems, Inc. gary@sci34hub.sci.com
The sysadmin sees all, knows all, and doesn't tell the boss who's
updating their resumes.... This .sig Copyright G. L. Heston, 1990crissl@rulcvx.LeidenUniv.nl (Stefan Linnemann) (11/14/90)
In <16754@teda.UUCP> ardai@teda.UUCP (Mike Ardai) writes: >In article <1990Nov12.161416.20549@mccc.uucp> pjh@mccc.edu (Pete Holsberg) writes: >-In article <554@6sceng.UUCP> blm@6sceng.UUCP (Brian Matthews) writes: >-=In article <736@dynasys.UUCP> jessea@dynasys.UUCP (Jesse W. Asher) writes: >-=|0 0 658135267 0 SUCCESSFUL rutgers >-=| ^^^^^^^^^ >-=Huh? It's Nov 8 23:21:07 1990, plus or minus time zone differences. >-Could you explain how you got Nov 8 23:21:07 1990 out of 658135267??? Thanks. >(We are running on Eastern Standard Time here) >main() >{ > long l = 658135267; puts(ctime(&l)); >} >Fri Nov 9 07:21:07 1990 >-- >\|/ Michael L. Ardai Teradyne EDA East >--- ------------------------------------------------------------------------- >/|\ ...!sun!teda!ardai (preferred) or ardai@bu-pub.bu.edu I've got a simple program for this: $ secdate 658135267 658135267 = Fri Nov 9 07:21:07 1990 GMT = Fri Nov 9 08:21:07 1990 MET It also recognizes DST if applicable. If anyone is interested, I'll post it to comp.sources.misc or alt.sources. Stefan. | Stefan M. Linnemann, a.k.a. crissl@rulcvx.LeidenUniv.nl | | | Life is like the odd bit of string: it should be long enough to do Something Extremely Useful with it, but for all of the really neat | things we think of, it's just too short. | | -- Me, 1990, as far as I know; correct me if I'm wrong. |
kenny@albert.ai.mit.edu (Kenny Goldman) (11/15/90)
Yah.. I think what that huge number represents is the number of seconds elapsed since UNIX's "birth" of sorts. I believe the date/time was something to the effect of January 1, 1970 UTC (Greenwich Mean Time) - If you want to sit there and divide, go ahead, but I think that's right :-) -- -- Kenneth Goldman (kenny@ai.mit.edu) Cybernetic Musical Research, Inc. 1201 36th Ave.
guy@auspex.auspex.com (Guy Harris) (11/17/90)
>The date is the internal format, which is defined as the number of seconds >since January 1, 1970. January 1, 1970, midnight *GMT* (or UTC), specifically - i.e., the correct value for the internal time on *all* UNIX machines on Planet Earth, as of the moment I the the last character in this sentence, is the same (most machines, in practice, probably don't have the *exact* correct value, of course...). >(Reportedly day 0, year 0, of the age of Unix.) Possible, but unlikely. The original PDP-7 (*sic*) UNIX is, in an article by Ritchie and Thompson, claimed to have first shown up in 1969; unless it showed up *very late* in 1969, it couldn't have been January 1, 1970, midnight GMT. >All Unix dates are maintained in this format, for some reason; One reason is that, as indicated above, internal UNIX dates don't have to worry about time zones, daylight savings time, etc. That's why the timer (generally) in the kernel maintains time in that format; that timer is used to time-stamp files, and is the timer you get when you ask the OS for the current time. Since it's the timer you get when you ask the OS for the current time, and you have to do more work to convert it into local time, most programs tend to store it rather than some representation of local time.
pcg@cs.aber.ac.uk (Piercarlo Grandi) (11/19/90)
On 16 Nov 90 19:03:20 GMT, guy@auspex.auspex.com (Guy Harris) said: guy> January 1, 1970, midnight *GMT* (or UTC), specifically - i.e., the guy> correct value for the internal time on *all* UNIX machines on guy> Planet Earth, [ ... ] guy> One reason is that, as indicated above, internal UNIX dates don't guy> have to worry about time zones, daylight savings time, etc. The essential reason is that UNIX was almost immediately a networked environment (UUCP a very early development), and the internal BTL UUCP network was spanning several time zones; this meant that all the machines had to use the same time base for stamping files, or all sorts of distributed sw engineering operations, like software distribution (uucp), or distributed makes (uux make), would not work across time zones. DEC with VMS made the catastrophic mistake of using local time as the time base, and any DEC VMS site that shares files with sites in other time zones has had big big problems. For the same reason above, Internet and UUCP mail dates are required to be stamped wither with the GMT time or with local time and an indication of the time zone, so that GMT time can be deduced. Otherwise, when e.g. sorting a mailbox by date sent, some replies from another time zone could appear before the questions... -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk