From: Robert Eden <rmeden@ya...> - 2004-10-23 16:57:29
First let me confirm that I know there was not a Windows EXE release
for 0.5.35. That version never worked on windows so an EXE was not
generated. The pre-release version to http://alpha-exe.xmltv.org
includes a working tv_grab_uk_rt. Hopefully 0.5.36 will be out soon.
In the U.S. we're coming up on the switch from Daylight Savings Time to
We know most XMLTV utilities don't deal with this as well as it should.
There was hope this would be addressed by this time change, but we
didn't make it.
The best way to deal with DST issues is to process everything in UTC
and then convert to a local time zone on display. The upcoming XMLTV
schema (no time frame) will *REQUIRE* UTC in the XMLTV file.
Application authors should prepare for it, both to improve DST
operations and to prepare for the next schema.
Converting to UTC is a challenge for those grabbers that use web
scrapers. Most web sites convert everything to local time for display
without mentioning the time zone. Some of the source web sites don't
to great job of dealing with DST either.
The US/CA grabber, tv_grab_na_dd receives data in UTC. The default
output mode is also UTC. There is an optional "Time offset" parameter
that can be used to adjust for local timezone and UTC changes. Note
the therm "time-offset", not "time-zone". A time-offset is a dumb
offset and must be adjusted for timezone and/or DST.
If you have an application that requires a local time zone, you can
make pre and post DST _dd runs (specify --days, --offset and use a
different config file) and then combine them with tv_cat.
Unfortunately, one of those applications that doesn't handle UTC is my
own tv_check. I am still planning a rewrite, but haven't gotten to it