13 Oct
2020
13 Oct
'20
6:52 a.m.
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
13 Oct
13 Oct
9:17 a.m.
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(a)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
7:13 p.m.
On Tue, 13 Oct 2020 11:17:27 +0200
Ján Máté <jan.mate(a)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.
7:30 p.m.
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(a)datanom.net> wrote:
On Tue, 13 Oct 2020 11:17:27 +0200
Ján Máté <jan.mate(a)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.
10:04 p.m.
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(a)squirrel.nl> wrote:
On Tue, 13 Oct 2020 21:30:41 +0200, Ján Máté <jan.mate(a)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 ?
629
days inactive
629
days old
5 comments
3 participants
participants (3)
-
Johan Vromans -
Ján Máté -
Michael Rasmussen