Puzzled with Time Server conversion problems?

[Benjamin Schollnick]

On Mon, 4 Oct 1999 07:12:29, "Malcolm Tredinnick" 
<malcolmt at smart.net.au> wrote:

> > 	The RFC states that "The time is the number of seconds since 00:00 @ 
> > 1900 Jan 1.

> > 	From my experimentation is GMTIME:
> > 
> > python MKTIME calcs				RFC 868
> > (Base 1970, Jan 1)		          (Base Jan 1, 1900)
> > Jan 1, 1970	- 18,000.0			2,208,988,800
> > Jan 1, 1976	- 189,320,400.0			2,398,291,200
> > Jan 1, 1980	- 3,155,550,800.0		2,524,521,600 (CORRECTION)
> 
> I assume there is a typo here, since the correct value for Jan 1, 1980
		(Fixed)

> > I don't see how python's Jan 1, 1980 calcuation can exceed the RFC's 
> > calculation, unless the
> > calculation is returning *NON-LINEAR* results, which doesn't make 
> > sense if it's the # of secs since
> > Jan xxxx.
> 
> I agree. I can't understand your Python numbers at all. There is a
> problem with your calculation routine (see below), but it shouldnt'
> give these non-linear results. I don't have access to Python on any
> sort of Windows box, so I can't verify the results you got there, but
> certainly nothing like that is happening under Linux for me.

Well, both Os/2 v1.52 & Win32 v1.52 return the same values, so I 
assume
that it's the same most platforms.

I simply:

>>> import time
>>> print time.gmtime(0)
(1970, 1, 1, 0, 0, 0, 3, 1, 0)
>>> print time.mktime(1970, 1,1,0,0,0,3,1,0)
18000.0
>>> print time.mktime(1980, 1,1,0,0,0,3,1,0)
315550800.0
>>>

...etc....

> > Also, I can't duplicate the RFC 868 values if I manually perform the 
> > calculations.
> > 
> > My "big question", is simple:
> > 
> > 	Can anyone suggest a way to convert from pythons time.time() to the 
> > RFC date(s)?
> [... lots'o stuff deleted ...]
> 
> > import time
> > #
> > #       Constants
> > #
> > #secs_in_year    = 31536000      # 365*24*60*60
> > secs_in_year    = 365.1666666666667 * 24*60*60
>                         ^^^^^^^^^^^^
> Huh?? Firstly, since 0.166666... = 1/6, this is saying that leap years occur
> every six years. On my side of the world at least, we try to have them
> every four years or so. :-)

I *AGREE*, but that's what I got when I reverse "engineered" the 
calculations from the RFC.
Which is why I'm starting to shake my head, and go, "Who thought this 
@#$@ thing up". >g<

         		2398291200
	-	2208988800
		-----------------
		  189302400
	/		     6
		  ----------------
			356 (1/6)

Which actually is the distribution of the time over the 6 years.... So
your right, but, when I 
tried the "common" year values (356, 355.4, 356 1/4) nothing was 
working to match
the RFC, so I tried to calculation a "match".

I suspect that it's a flaw in my formula..

> To conclude, here is a corrected version of the manual calculation
> code. 

Thanks, I'll shake it out and see how it works.

I'll be posting the final product in here...

> I have, in passing, fixed one other error, which is that to work
> out the number of seconds from the beginning of the year until the
> current day, you should use (Julian Day - 1), not just Julian Day.
> This code assumes a 1/1/1970 epoch - just add the appropriate big
> number is you want to work from 1/1/1900. :-)

> Malcolm Tredinnick

Thanks Malcolm, I've been hitting my head against the wall for a 
couple of days!

			- Benjamin

================================
Please feel free to copy any and or
all of this sig.
A little something for spam bots:

root at localhost postmaster at localhost admin at localhost
abuse at localhost postmaster at 127.0.0.1

Chairman William Kennard: bkennard at fcc.gov 
Commissioner Susan Ness: sness at fcc.gov
Commissioner Harold Furchtgott-Roth: hfurchtg at fcc.gov
Commissioner Michael Powell: mpowell at fcc.gov
Commissioner Gloria Tristani: gtristan at fcc.gov
consumerline at ftc.gov
fccinfo at fcc.gov
ssegal at fcc.gov