Eugene van der Pijll wrote: >So: perhaps it would be better to create a single method, returning a >DateTime::Span object? And then make iterating methods that accept these >spans:
That's a reasonable interface, if one can take DT::Span as ubiquitous. It's certainly convenient if one really does want the interval rather than the boundary. Arguably also makes the method names more understandable when dealing with the boundaries ($tz->observance($dt)->end, for example). I suggest the method name "observance_span" instead of "observance", to distinguish it from a hypothetical method that would return a reification of the observance itself (as Dave mooted elsewhere on this thread). Could also append "_for_datetime" if we want to fit in with the existing so-named methods. >Only problem is that DT::TimeZone would have a dependency on DT::Span >now. There's a circularity there: DT::Span's CPAN distribution depends on DT, which depends on DT::TZ. DT::TZ doesn't currently depend on DT. DT::Span also looks quite heavyweight. Brings in DT::Set, Set::Infinite, and DT::Duration, even if one is only using it to wrap a pair of endpoints. Not sounding like such a good idea now. Maybe we need a DT::Span::Lite. Another possibility: as the span-based interface is conceptually handy, there's the option to have a lightweight DT-based interface in each DT::TZ class, and put the heavy span-based interface in a base class, wrapping the lightweight one. -zefram
