There are many problems as the industry tried to establish a calendaring/scheduling standard.
Less technical.
Technially speaking everything seems to be solved (for me).
The problem is rather – I think – in the plethora of ways people (in real life) work with calendars, and how their understanding of scheduling is.
One of the problems is e.g. with the understanding of recurring events (not covered today). The other is with time zones, and how people ignore them.
Yes - time zones.
We thought, that the problems of specifying a local time were actually solved with the invention of time zones.
Still, what do you do (programmatically, not as a human being), when you receive an calendar event without any time zone information.
Not even a UTC marker (as in the generally accepted ISO8601 standard).
Which time zone does this event fall into?
In real life you say “The time zone of the organizer or the person you received the invitation from (i.e. the sender)”, and you are usually able to resolve this, because in real life you at least have a hint what their time zone might be.
As a program, how do you tell – in the absence of any TZ information?
Which TZ do you pick?
Is it fair to assume that then sender has the same TZ as you (the receiver) has?
Or should you just shoot programmers who do not include TZ information in their events?
Or is it the standard ? ISO8601 allows for empty TZ information and simply declares those as being "local". Local to what?
The voting is open ... :-)
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment