Jim Bacon wrote: >Yes, provide methods for finding any type of transition besides DST, but I >think DST might be the most common and should therefore have as many >shortcuts as needed to simplify its use.
I'm not convinced that finding the DST change dates in a given Gregorian calendar year is going to be a particularly common usage. It seems more likely that one would want to know the next observance (or offset) change from the present, whether that's due to conventional DST or for any other reason. Anyway, here are my thoughts on non-general-case methods: I don't want to have to reimplement them all in each independent timezone class. Let's implement them generically, in terms of the general-case methods. They don't, of course, strictly need to be methods; they can perfectly well be ordinary functions in an independent module. (So you can have a module that looks up DST changes in a given Chinese lunar year, for example.) Anything that's of sufficiently wide use to justify being a method can go into a base class that all timezone classes inherit. Since DT::TZ contains the machinery for the parsed-Olson classes, I think it should not itself be the mandatory base class; better to institute a DT::TZ::base. I'm principally interested in the general-case methods. I think we ought to establish the general-case inteface first, and do the syntactic sugar later. We have arbitrarily long to add more sugar methods to the base class, but the underlying general methods form a contract between independent bits of code, so other work depends on them. -zefram
