Hello, On Feb 2, 2010, at 16:48 , Patrick Ohly wrote:
> When Congwu tested direct synchronization with the Nokia N7120c, he > found that certain workarounds were needed (see patch below). > > Congwu, I'm not entirely sure why the "TZ" property is needed when we > force using UTC. Is it for events coming from the device? Events coming in "local time" from the device would be the only reason for *needing* a TZ. > In that case, how is the DTEND value handled? This is automatic. When a TZ/DAYLIGHT is encountered, the time zone derived from it becomes the "item time zone", which means that any non-UTC (=non Z suffixed) time value found in the vCalendar entry automatically is interpreted in this zone. The assignment of "TZ" (and "DAYLIGHT") to the "DTSTART" field is only relevant when generating a vCalendar item - it means that the time zone of DTSTART is used to generate an appropriate TZ/DAYLIGHT (while the DTEND, RR_END etc. fields could have other zones assigned). > What was the advantage of forcing UTC when it supports TZ? I would not trust an implementation that has the TZ in the wrong place (it does not belong into VEVENT, but outside according to vCalendar 1.0 specs) to do anything useful with it. Moreover, TZ alone is pretty useless without DAYLIGHT in most zones. So sending in UTC is much safer. If the receiver gets TZ correctly, all the better, but if it does not, then at least the absolute time will be ok. > Suppose we have multiple devices which all need this special "TZ" > property. > > Lukas, is there a way to do this without adding one <property> > entry per device? I think we discussed this before, but did we come to a > conclusion? No, AFAIR (R=remember). The question is if there's really one rule needed per device, or if something like that extra TZ at the wrong place only affects a number of Nokia devices which can be caught by a single rule (wildcards can be used for rule matching). If that's not sufficient, I'd propose extending the rule matching mechanism itself according to the multiple-rule capabilities that are already present: using <finalrule>no</finalrule>, the search for matching rules can be continued, and options specified by the rules will be accumulated. However only the last matching rule counts as the "current" rule. This could be enhanced as follows: a) collect all rules that did match in a list, such that we can have multiple "current" rules. b) add a <includerule> option for rules, such that a specific rule (say: "7210c") could activate other more general rules (say: "needsTZinVEVENT") which would also be added to the "current" rule list. Things like that TZ could then be made depending on such a general rule rather than the device rule itself. This would be reasonably easy to implement (I can do it if we agree that this would be a useful solution) and would allow quite structured rule trees without repeating common parts. Best Regards, Lukas Zeller ([email protected]) - Synthesis AG, SyncML Solutions & Sustainable Software Concepts [email protected], http://www.synthesis.ch _______________________________________________ os-libsynthesis mailing list [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
