Zefram schreef:
> Dave Rolsky wrote:
> >However, something with some of the same info seems like a natural thing
> >to return from these methods.
>
> So we'd have a DT::TZ::Observance class, with methods ->offset,
> ->short_name, ->is_dst, ->start_datetime, ->end_datetime.
> $tz->observance_for_datetime($dt) would return one.
Or: instead of making observance_for_datetime a method in the standard
TZ distribution, make a separate distribution, with class
DT::TZ::Observance (or maybe somewhere in DT::Util? DT::Ev?).
That would make it much more acceptable to include a prereq on DT::Span.
Then creating an observance could be like this:
$dt->set_timezone( 'America/New York' );
$obs = DT::TZ::Observance->from_datetime($dt);
(DT objects already contain a timezone; why not just use that one?)
> Re DT::Span (see other subthread), could have a ->span method that
> loads DT::Span in all its glory and returns one.
DT::TZ::Obs could even be a subclass of DT::Span.
> Would DT::TZ::Observance have methods ->next and ->prev? Would make
> walking the chain easy.
Yes.
> Raises questions of implementation strategy.
Better to raise those questions once, in the implementation of the
class, than with almost every use of the class.
> If we're going to go the heavyweight route, this is the way to go.
If the method is not included in the standard distribution, there is no
problem with going the heavyweight route.
DT::TZ would than have to implement just a single method to get at the
raw data; for example DT::TZ->get_transition( $dt ), which returns the
first transition after $dt, or the first transition if no $dt is passed.
Then DT::TZ::O could use all timezone modules that implement such a
method.
Eugene
