Timetuple or local time gives error before 1970.

[John Duchek]

I have been searching down a particular event on the moon. (Observation of Plato's hook). It is a shadow that only appears infrequently. In order to test my search program, I needed to search a period in 1952. I was using the timetuple (as shown in the datetime object in the pyephem directions. timetuple=(1984,5,30,12,23,45) is the example you use. It works fine for all dates since 1970, but when 1969 or earlier is put in it says

C:/Python25/pythonw.exe -u "L:/Python_SC_2009/Platos_hook.py"
Traceback (most recent call last):
  File "L:/Python_SC_2009/Platos_hook.py", line 27, in <module>
    local = localtime(john.date)
  File "C:\Python25\Lib\site-packages\ephem\__init__.py", line 427, in localtime
    timetuple = time.localtime(calendar.timegm(date.tuple()))
ValueError: (22, 'Invalid argument')

here are lines 25-27
timetuple=(1952,mon,d, h,m,0)
                john.date=timetuple
                local = localtime(john.date)

All of these lines work fine with a value of 1970 or higher.
John

[Brandon Rhodes (brandon-rhodes)]

The exception is a limitation of your operating system — when PyEphem asks it to convert the given UTC date and time into a local date and time, it finds the date too far in the past or future to represent under your operating system, and gives up.

Strictly speaking, of course, asking about the "local time" of an event too far in the past is meaningless, because time zones didn't exist until recently, and before that there was no strict definition of your location's "local time" to use. :-) But you're probably doing early-twentieth-century calculations to which such a complaint doesn't apply: time zones certainly existed then, your computer operating system just can't think about times that long ago.

I'll look around at the available time libraries for Python, and at least add to the docs a discussion of how to use one of them to do this calculation.

[John Duchek (johnduchek)]

You are correct, sir! The program runs fine under linux, coughs up the
error in Windows XP. Just one more reason to use Linux.

John

Brandon Craig Rhodes wrote:
> The exception is a limitation of your operating system — when PyEphem
> asks it to convert the given UTC date and time into a local date and
> time, it finds the date too far in the past or future to represent under
> your operating system, and gives up.
>
> Strictly speaking, of course, asking about the "local time" of an event
> too far in the past is meaningless, because time zones didn't exist
> until recently, and before that there was no strict definition of your
> location's "local time" to use. :-) But you're probably doing early-
> twentieth-century calculations to which such a complaint doesn't apply:
> time zones certainly existed then, your computer operating system just
> can't think about times that long ago.
>
> I'll look around at the available time libraries for Python, and at
> least add to the docs a discussion of how to use one of them to do this
> calculation.
>
> ** Changed in: pyephem
> Importance: Undecided => Medium
>
> ** Changed in: pyephem
> Status: New => Confirmed
>
> ** Changed in: pyephem
> Assignee: (unassigned) => Brandon Craig Rhodes (brandon-rhodes)
>
>

[Brandon Rhodes (brandon-rhodes)]

Having looked at the options, I am not excited, at the moment, about making PyEphem depend on a third-party time zone library, nor do I want to include such a database inside of PyEphem itself. So for now PyEphem will stay firmly ensconced at Greenwich time, and your operating system — or a third-party time library of your own selection; have you tried pytz? — will have to translate for you as best it can.

Thanks for reporting this issue, though! If I ever get time to play with pytz, then I could add a section to the PyEphem documentation about using it for translation.