On Tue, 14 Jan 2003, srl wrote:
> > > gives:
> > > [19700329T020000..19701025T030000],
> > > [19710328T020000..19711031T030000],
> > > [19720326T020000..19721030T030000]
> > >
> > > The format of the time strings and the recurrence rules are defined
> > > in the iCalendar rfc (2445). This was used because the primary use
> > > of Date::Set was going to be Net::ICal. (not that I'm aware of
> > > any other syntaxes to specify recurrences in)
> >
> > Wouldn't it be better to specify them in something a little more primitive
> > (numbers, not a string)?
>
> In iCalendar, the string has significance, because timezones
> can be specified as part of it:
>
> "19720326T020000Z" is that date/time in UTC;
> "19720326T020000;America/New_York" is that date/time in New York,
> whether New York's in daylight savings or standard time.
I was just suggesting that those are better stored in a more optimized
manner, perhaps, since Perl doesn't natively operate on ICal strings. And
in the case of storing sets for datetimes, the datetimes stored should
almost definitely be in UTC.
> > The base object will store UTC only, and then use the timezone objects to
> > do other things. So if we 19700328T233000Z and add 4 hours, we end up
> > with 19700329T033000Z. And if the timezone is Europe/Amsterdam, then when
> > the user asks for ->hour, they get the right answer.
>
> Where "right answer" involves knowing whether Amsterdam is in
> DST or not right now, I assume?
Right. It'll look something like this:
my $dt = DateTime->new( ical => '19700328T233000' );
$dt->add( hours => 4 );
$dt->set_timezone( $amsterdam_tz );
print $dt->hour;
then internally
my $offset = $self->timezone->offset_for($self);
return ($self + $offset)->hour;
Where convert_to_tz looks like this:
sub offset_for
{
my ($self, $dt) = @_;
# do a lookup to find if $dt represents a DST or non-DST time
return $appropriate_offset; # as DateTime::Duration object
}
This could obviously be optimized, but the point here is to show the
separation of responsibilities. DateTime.pm _only_ knows about UTC times.
Timezone objects generate an offset _based on a given UTC time_. There's
no such thing as an offset without a specific datetime.
-dave
/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
