Puzzled with Time Server conversion problems?
Benjamin Schollnick
junkster at nospam.rochester.rr.com
Mon Oct 4 06:11:21 EDT 1999
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
More information about the Python-list
mailing list