Opened 8 years ago

Closed 8 years ago

#23 closed defect (fixed)

Some of the 'optional' parts of VTIMEZONE should perhaps be tagged as required for the server situation

Reported by: lester Caine Owned by: cyrus@…
Priority: major Milestone:
Component: service Version:
Severity: Active WG Document Keywords:
Cc:

Description

Can you enumerate some specific things you think are missing from
VTIMEZONE? The fact remains, that for the most part, "consumers" of
VTIMEZONE are typically focussed on only a small period of time (recent
past to recent future) as is the nature of events created and managed by
iCalendar clients.

Some of the 'optional' parts of VTIMEZONE should perhaps be tagged as
required for the server situation? I've identified the pre-timezone
niggle on name, and I think a 'start-date' with the list return covers
the data.

I'm not sure that we can transparently convert VTIMEZONE rules back to
the underlying tz data simply because tz DOES reuse rules across
multiple timezones and that information is lost in translation. A master
server can retain the source material, but a slave server will have to
be able to update only from the expanded data which is where I see a
problem with short notice change 'race hazards'. We get problems with
clients hitting actions within fractions of a microsecond. If timezone
servers are taking half a day to sync ....

Change History (2)

comment:1 Changed 8 years ago by lear@…

  • Component set to service
  • Owner set to cyrus@…
  • Severity changed from - to Active WG Document

comment:2 Changed 8 years ago by lear@…

  • Resolution set to fixed
  • Status changed from new to closed

We believe this issue is addressed by the URL redesign, Issue 32, and the data truncation issue.

To be closed.

Note: See TracTickets for help on using tickets.