time, calendar, datetime, etc
adalke at mindspring.com
Sat Aug 2 00:33:16 CEST 2003
> See my response to Andrew Dalke. The basic issue is that the starting
> date is too late to be useful.
And my reponse is you should have said "... to be useful for you."
It's plenty useful for me and others.
Though if I were to do long baseline interferometry, using a
couple of masers to keep things in synch, then I expect that
datetime would also not be useful for me because I would need
better than microsecond resolution.
When should datetime functionality stop growing to support
smaller and smaller niches?
> I wouldn't have any problem with wrapping it to get what I want, but
> the base date issue is intractible in any significant sense. The remainder
> of Andrew's straw men are clearly in extension territory.
"Intractable?"! What about defining your own class which handles
BC dates, using datetime to do the heavy load? All you need is
your own offset to choose a year which has the same day-of-week
and leapyear behaviour. datetime says 1/1/1 was a Monday, so
you just need a year offset X so that 12/31/X is a Sunday and
where X is a leapyear (or not? Don't know how the leap years
are affected that far in the past.). Looks like X=6000 does the
>>> datetime.date(1970, 8, 22).weekday()
>>> datetime.date(6970, 8, 22).weekday()
So what about an offset of 6000 years? Implement your
own class which uses datetime for storage, and just subtract
6000 years from its result to get the real result?
def __init__(self, year, month, day):
self._date = datetime.date(year + 6000, month, day)
year = property(lambda self: self._date.year - 6000)
month = property(lambda self: self._date.month)
day = property(lambda self: self._date.day)
def weekday(self): self._date.weekday
d = RothDate(-200, 2, 10)
print d.year, d.month. d.day
Doesn't seem that intractable to me, excepting leapyear
behaviours. And is there consensus on that?
dalke at dalkescientific.com
More information about the Python-list