Re: Daylight savings ending not being accounted for in grab_na

On Sun, Oct 27, 2002 at 07:15:13PM +0000, Ed Avis wrote:
> 
> Whatever timezone is most appropriate to the listings data.

That's fair, as long as the time representation is accurate.  The
question remains however, when future data is written, is it written
with times in the current time zone or the time zone when the program
is being shown?

> If you
> fetch data from Peru, you'd expect it to use Peruvian Standard Time or
> whatever.

Right.  If the program is showing during Standard Time.

> The result of running tv_grab_pe must not vary depending on the user's
> current timezone any more than it should depend on the user's current
> language.  The data returned is that from the site, formatted into
> XML.

Agreed.  But I don't think any of this discussion revolves around
representing data in alternate timezones.  The whole point is whether
future data should be represented in the timezone at the fetch time or
the timezone of the showing time.

> From my viewpoint as a user, I want the listings to be returned in the
> timezone given at the listings source and not converted to other
> timezones just for the sake of it.  For example if I'm looking at the
> Swedish TV listings it makes much more sense to see the breakfast show
> at 06:00 Swedish time rather than 04:00 British time or whatever.

Ed.  Peace already.  I am not advocating writing data in alternate
timezones!  I am merely interested in the data being accurate in the
local time zone.  In the case of the NA grabber, it is not.  When data
for post-DST programmes is fetched during DST, it is written with a
post-DST time and a DST time zone specification.

[ much irrelevant (because I agree with it) discussion about convering
  data to alternate time zoned deleted ]

b.

-- 
Brian J. Murrell

pgpgvZLxUJ3LR.pgp
Description: PGP signature