Then please consider what might be the most common use, where one needs to easily find the DST transition date, forward or back, for any given year. The ideal mehtods for me (being selfish) would be a method that returns a DT object set to the first second (or nanosecond) in the TZ being transitioned to.
So simply for ease of use, as opposed to completeness for all possible transitions in a given TZ, you would have calls like $dt->start_dst and $dt->end_dst as setters when called as instance methods, and conceivably $dt_start = DT->start_dst( year =>2003 ) and $dt_end = DT->end_dst( year => 2009 ) returning DT objects as constructors, as well as the next_dst and prev_dst variations suggested elsewhere. Simply put, I don't want to have to code a lot of extra logic in every app for what should be common lookups. 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. Thank you for your consideration of this. Jim > -----Original Message----- > From: Zefram [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 06, 2007 11:36 AM > To: datetime@perl.org > Subject: Re: Help pulling dst change dates from DateTime::TimeZone > > > 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. > > -zefram >
