Re: Daylight savings ending not being accounted for in grab_na

On Mon, 28 Oct 2002, Jerry Veldhuis wrote:

>2. zap2it over the time-change failed to provide listings that were
>   consistant before or after the time-change.

Nothing you can do about that really.  So we just have to focus on
listings that are definitely in one tz or the other.

>3. tv_grab_na (and presumably other grabbers, currently or future ones)
>   use Date::Manip Date_TimeZone function (which relies on TZ or `date`)

Instead, IMHO, it should set this at configure time, since
Date_TimeZone() returns the user's local tz which may not be correct.

>4. tv_grab_na only understands this is a string representing the timezone
>   and appends it to the xml date strings as such.

That is okay.

>6. tv_grab_* "should" provide a way to grab listings from a different
>   location (currently done by setting TZ in tv_grab_na's case).

When the location (postal or zip code) changes the tz may also
change.  So it should be configured in the same place.

>8. since Date::Manip doesn't handle timezone changes, tv_grab_na has
>   no way of knowing when the time change occurs.

However it would be possible to do what tv_grab_uk_rt does and have a
library which know about the transitions to/from summer time and can
deduce the correct tz given a date and time.

>I've looked at a couple of perl packages and I see that Cal::Date
>looks like it might help.

Or we could generalize the existing UK_TZ.pm library.  Ideally I would
like to make an addition to Date::Manip for better tz handling (its
biggest weak spot IMHO) and eventually get this included
upstream.  But that's a way off yet.

-- 
Ed Avis <ed@xxxxxxxxxxx>