Hi,
All my appointments take place in the central Europe timezone (Europe/Amsterdam) and hence each VEVENT contains a VTIMEZONE section for Europe/Amsterdam. This accounts for more than 90% of the event data, something I consider a big waste. It also violates one of the principles of information technology: avoid duplicating data.
Is including VTIMEZONE data mandatory or can it be stripped?
-- Johan
Hi Johan,
CalConnect is working on something what will fix this issue (a new specification how to work with timezones). The problem is that until everybody adopts the new approach you CANNOT remote existing VTIMEZONE components.
JM
On 13 Oct 2020, at 08:52, Johan Vromans jvromans@squirrel.nl wrote:
Hi,
All my appointments take place in the central Europe timezone (Europe/Amsterdam) and hence each VEVENT contains a VTIMEZONE section for Europe/Amsterdam. This accounts for more than 90% of the event data, something I consider a big waste. It also violates one of the principles of information technology: avoid duplicating data.
Is including VTIMEZONE data mandatory or can it be stripped?
-- Johan
On Tue, 13 Oct 2020 11:17:27 +0200 Ján Máté jan.mate@inf-it.com wrote:
Hi Johan,
CalConnect is working on something what will fix this issue (a new specification how to work with timezones). The problem is that until everybody adopts the new approach you CANNOT remote existing VTIMEZONE components.
According to the RFC a VEVENT may contain a VTIMEZONE component which means it is optional. Also according to RFC: If a VEVENT does not contain a VTIMEZONE a user configured default time zone is used and as a last effort resort to use local time zone for server/client. Eg last resort is 'Z'.
Hi Michael,
that's true, but the "local timezone" is usually problematic (e.g. DST, ...).
JM
On 13 Oct 2020, at 21:13, Michael Rasmussen mir@datanom.net wrote:
On Tue, 13 Oct 2020 11:17:27 +0200 Ján Máté jan.mate@inf-it.com wrote:
Hi Johan,
CalConnect is working on something what will fix this issue (a new specification how to work with timezones). The problem is that until everybody adopts the new approach you CANNOT remote existing VTIMEZONE components.
According to the RFC a VEVENT may contain a VTIMEZONE component which means it is optional. Also according to RFC: If a VEVENT does not contain a VTIMEZONE a user configured default time zone is used and as a last effort resort to use local time zone for server/client. Eg last resort is 'Z'.
-- Hilsen/Regards Michael Rasmussen
Get my public GnuPG keys: michael <at> rasmussen <dot> cc https://pgp.key-server.io/pks/lookup?search=0xD3C9A00E mir <at> datanom <dot> net https://pgp.key-server.io/pks/lookup?search=0xE501F51C mir <at> miras <dot> org https://pgp.key-server.io/pks/lookup?search=0xE3E80917
/usr/games/fortune -es says: The world really isn't any worse. It's just that the news coverage is so much better.
On Tue, 13 Oct 2020 21:30:41 +0200, Ján Máté jan.mate@inf-it.com wrote:
that's true, but the "local timezone" is usually problematic (e.g. DST, ...).
True, but if it is a well-established timezone line Europe/Amsterdam a.k.a. CET ?
CET will change to CEST (summer time), without timezone the time offset information will be lost ...
JM
On 13 Oct 2020, at 23:59, Johan Vromans jvromans@squirrel.nl wrote:
On Tue, 13 Oct 2020 21:30:41 +0200, Ján Máté jan.mate@inf-it.com wrote:
that's true, but the "local timezone" is usually problematic (e.g. DST, ...).
True, but if it is a well-established timezone line Europe/Amsterdam a.k.a. CET ?
-
Johan Vromans -
Ján Máté -
Michael Rasmussen