On Tue, Mar 06, 2007 at 04:35:52PM +0000, Zefram wrote:
> Jim Bacon wrote:
> >next_dst and prev_dst based on the year value of the DT object and a
> >parameter specifying if what is wanted is the spring or fall date, or at
> >least specifying change to daylight time or standard time.
>
> Please no, not such a restrictive model. That'd be a nightmare. Timezone
> offset changes are a lot more complicated than just a twice-yearly
> alternation between two possibilities. There are years with more than
> two changes, and years with only one change or no change at all.
>
> With the generic arrangement, where you get the next/previous observance
> boundary working from an arbitrary DT, if you happen to know that your
> timezone fits the twice-yearly-change pattern, you can do next from
> the start of the year or previous from the end of the year to find the
> two boundaries.
It might make sense in that case to return the observance date and somehow
return the change that happens, or add another call that returns that data
for that change. Maybe return a datetime object and a duration object? Or
have a separate call that returns a duration.
--
www.suave.net - Anthony Ball - [EMAIL PROTECTED]
OSB - http://rivendell.suave.net/Beer
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Which of my enemies told you I was paranoid?
