You are here

Times, time-zones and DST corrections.

The first thing to realize is that there are two time-zones involved in the times in your final EPG, each with its own DST rules; the time-zone for which the times of the guide is provided (the 'source' time-zone) and the time-zone of the user (the 'target' time-zone). In the majority of cases these two are equal, but that doesn't change the fact that there are two to consider.

In principle the guide times must be corrected for UTC offset and DST changes for both these two time-zones:  The first correction, the one for the 'source' time-zone, is done by WG++ and the second, for the 'target' (should be done) by the some piece of software at the viewers side, probably the PVR xmltv importer.

Before upgrade 53 , WG++ was unable to identify the 'source' time-zone correctly, the only info available about it was the time-zone value in the siteini. But that value was limited to just an UTC offset, not the proper time-zone_id and the DST rules for that. (The reason for that limitation lies in the fact that timezone_id's are not standardised among the varies computer platforms, Windows, Linux, OSX, for which WG++ should work) Therefore the DST correction that WG++ applied for the 'source' time-zone was done with the DST rules of the 'target' time-zone. Consequently, the DST changeover dates applied for the source time-zone were the DST changeover dates of the target time-zone. Although wrong in principle, it is only a problem if these DST changeover dates are different, which is possible but unlikely. (no problem if the user lives in the 'source' time-zone).

When does this go wrong? Examples:

-  If a user in Europe want to use a guide from the US (the have different DST changeover dates), or any other mismatch of DST changeover dates.
-  Or if the source time-zone has no DST rules (no DST in that zone) and the user lives in a time-zone with DST rules. Or the opposite.
-  Or if the source time-zone is UTC (the guide times are not in any particular time-zone, just plain UTC or GMT). Any user living in a time-zone with DST rules will run into problems because WG++ will apply the DST rules of the viewer to the xmltv startime which was meant to be UTC without any DST rule.

This was the situation before upgrade 53. The problems explained above can be 'corrected', temporary, by either changing the time-zone value in the siteini or by using the small utility xmltv_time_correct, (available @ on the download page) for the period of the mismatch of the DST rules.

All of that is changed with upgrade 53!  That includes an integrated international time-zone database that correctly identifies the source time-zone and the DST rule for that. (see the introduction of upgrade 53 on the download page and further down this page). With that, WG++ doesn't use the target time-zone any more. The two above mentioned DST corrections are completely separated, WG++ for the source, and the PVR for the target.

How to interpret the times in the xmltv file created by WG++?

By xmltv definition, the xmltv times are in UTC (GMT). The xmltv specification allows several formats for that and WG++ uses the one with the an utcoffset , yearmonthdayhourminutesecond +/-utcoffset or  yyyyMMddhhmmss +/-hhmm. The first part of that is (in most cases) the date and time presented in the tvguide of the source site, the second part is the actual offset of that with respect to UTC . E.g   start="20140602141500 -0500"  represents a local time at the source of 2014/06/02 14:15 (or 2:15pm) in a time-zone that is 5 hours behind (-) UTC. So , because the result is UTC by definition , this is 2014/06/02 19:15 UTC .

The eventual DST correction for the source time-zone is done by WG++ through changing the utcoffset with the effect that the result always remains the correct UTC time for this start-time.

What about the start-time for the viewer in his time-zone?

The calculation, to be carried out by some piece of program at the viewers side, probably the xmltv importer of the PVR program, must simply correct for the actual local UTC offset (corrected for DST if necessary). As example a few cases:

- Suppose the viewer is in the same as that of the source, which is quite normal. Then the start-time value of 2014/06/02 19:15 UTC will be corrected back to 2014/06/02 14:15.
- Suppose the viewers actual UTC offset is +8:00 (Singapore or there about), then this start-time is corrected to 2014/06/03 3:15 (next day early morning)

What if the times in your EPG appear to be wrong?

- Upgrade to V1.1.1.53 or higher.
- Check if the timezone in the siteini you are using is the correct one for the epg source site
- Check if the times in the xmltv file created by WG++ are indeed as described above (local epg source time and utcoffset)
- Make sure your computer is set to the correct timezone of your location, enable DST and check the time and date setting
- Try to figure out if the xmltv importer of the PVR you are using works as described above (correct for the actual local UTC offset). (Some importers have problems with xmltv files containing different utcoffsets , reading only the first one found and assuming this to be the only one)
- If still in problems post a question onthe forum



Brought to you by Jan van Straaten

Program Development - Jan van Straaten ------- Web design - Francis De Paemeleere
Supported by: