Subject: [iola-conversion-tool] Timezone

From: Adam Roach <[email-masked]>
Date: Thu, 22 Mar 2012 13:14:49 -0500

It looks like the timezone field on the meeting object for IETF 83 (more 
specifically, the proxy object) is returning GMT+1 for IETF 83. Since 
Paris goes into daylight savings time this weekend, I believe it should 
be +2. This is impacting the generation of the ics files from the 
datatracker page.

For example:

# wget -q -O- http://datatracker.ietf.org/meeting/83/agenda.ics?RAI | 
head -12
BEGIN:VCALENDAR
VERSION:2.0
METHOD:PUBLISH
BEGIN:VTIMEZONE
TZID:Europe/Paris
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+0100
TZNAME:Europe/Paris
DTSTART:19700101T000000
END:STANDARD
END:VTIMEZONE

That +0100 should be a +0200.

/a

---

From: Ole Laursen <[email-masked]>
Date: Thu, 22 Mar 2012 20:03:27 +0100

2012/3/22 Adam Roach <[email-masked]>:
> specifically, the proxy object) is returning GMT+1 for IETF 83. Since Paris
> goes into daylight savings time this weekend, I believe it should be +2.
> This is impacting the generation of the ics files from the datatracker page.

I had a look at the code, and the reason it says +1 instead of +2 is
that it's calculating the offset from the first day (Sunday) at zero
hour. :)

I've done a quick fix to have it calculate it from eight o'clock
instead (will be online when Henrik deploys it). I haven't worked with
iCal before, but it looks like one ought to dump both DST and non-DST
with separate labels and then output the right label for each entry?

Ole

---

From: Adam Roach <[email-masked]>
Date: Thu, 22 Mar 2012 15:40:37 -0500

> with separate labels and then output the right label for each entry?

Thanks for the fix! 

From an ical perspective, the time zone block should encode the DST rules for the locale under a single label. The old database only gave us an integer offset, so the output we presently generate is very primitive (and slightly wrong). It sounds like the new DB is much more intelligent about this kind of thing. Hopefully, my code refactor of the agenda code on Saturday will result in doing this correctly. 

/a

---

From: Ole Laursen <[email-masked]>
Date: Fri, 23 Mar 2012 13:18:49 +0100

> From an ical perspective, the time zone block should encode the DST rules for the locale under a single label. The old database only gave us an integer offset, so the output we presently generate i…

Ah, that sounds even better. Yes, we store a name, it's supposed to be
a name from the standard time zone database, I think. If you discover
some brokenness regarding that, it's probably better to fix the
database than continue with a hack.

Ole