I agree that storing the time of a given event in UTC as is done in the XAPIA format and in the callog file under /var/spool/calendar is going to create ambiguities with recurring events that cross a DST change. The program is forced to make assumptions about what the user wants, i.e. whether the event recurs at a fixed time in the user's timezone (implying a DST correction) or at a fixed time in UTC (implying that the time of the scheduled event will shift with the DST change).
It seems that dtcm_lookup is making the first assumption, and does not mix DST between North America and Europe, while dtcm's display does mix the DST changes. If the issue is limited to dtcm's display (for instance an incorrect call of a UTC to local time conversion function to determine whether a DST change has occurred that results in a default North American timezone say EST being assumed) it might be possible to correct it. If it is located at a deeper level, in rpc.cmsd or csa library, with two incorrect calls cancelling each other in dtcm_lookup, it is indeed better not to try to fix the bug, but to mention it in the documentation of the calendar. It would also be interesting to check whether the bug appears consistently on all operating systems to which CDE has been ported or is specific to the "System V" family that includes Linux and Tru64 UNIX. You are right that vCal or iCal file formats contain timezone information with event time, and avoid DST ambiguities for recurring events. But I have found that even for a personal use, the standalone calendar programs using vCal or iCal were either limited to monthly view (Orage in XFCE) or could freeze when entering simple appointments (Korganizer in KDE) or have become unsupported (Mozilla Sunbird). So dtcm retains some usefulness even if it has bugs or limitations that the user has to work around. Maybe the Motif programs plan or xdiary (if they only use local time to store events) could be a better alternative to recommend to CDE users if they don't need to share a calendar. Best, Edmond Orignac On 15/01/2016 15:22, Richard L. Hamilton wrote: > IMO, the problem has always been that (AFAIK) time zones were not recorded > when scheduling an event. That means that if the event is seen by people in > other time zones, it cannot be presented accurately - an event should be > scheduled in some particular time zone, adjusted as needed to UTC (an > adjustment that might have different values at different times of the year), > and then adjusted to the viewer's time zone as of when it's scheduled for. > If the storage format does not accommodate a time zone, this cannot be > correctly done. > > Look at csacsa(5) (just csa(5) on SunCDE) and the files in > /var/spool/calendar. > > Add to this the problem that POSIX style TZ specification may be complete (in > terms of describing change rule) or not, and if not, defaults are assumed > (either hard-coded in libc, or from the posixrules zoneinfo file); and that > zoneinfo files may be updated differently on different systems; therefore, > arguably a full expansion of the rules for the submitting client might have > to be stored too, unless one could make some simplifying assumptions (i.e. > that all zoneinfo or hard-coded equivalents are identical). > > It seems to me that fixing this would introduce a compatibility issue > (between the fixed and not fixed clients vs servers). There's also the > question of where adjustments should be made (client or server). Fixing this > in the best possible way would IMO be more difficult to design than to code. > > It also seems to me that modern calendar standards (icalendar format accessed > via CalDAV) do provide the capability to store time zone related info for > events (from a very quick look at the icalendar spec) - although I have no > idea if they use it correctly in nontrivial situations. So maybe a better > solution would be to abandon CDE's calendar manager and server (or keep them > only for compatibility with existing users, if any), and do all one's > calendar work with modern, open-source CalDAV servers and clients. > > I suppose one _could_ create an expanded version of dtcm that could talk to > either a CalDAV server or an rpc.cmsd server and make a best effort at doing > the right thing. But even that would IMO be a huge amount of work. > > >> On Jan 14, 2016, at 16:32, Edmond Orignac<edmond.orig...@wanadoo.fr> wrote: >> >> I have noticed a problem with recurring events in dtcm. >> I have created a weekly event "Séminaire" every Monday at 11am. >> For the month of March, I notice that the event will start at 11am except on >> March 14 and March 21 when it will start at 12am instead of 11am. (see the >> PNG in attachment) >> For the month of October, on the 31, the event will start at 12am (see >> second attachment). >> >> The problem does not occur with dtcm_lookup, and I am running the latest git >> version of CDE. >> >> A partial explanation of the problem is that the DST starts earlier in North >> America (March 13) than in Europe (March 27). It also ends earlier in Europe >> (October 30) than in the US (November 6). >> The anomaly thus occurs when North America will be on DST but not Europe. >> This suggests that for a recurring event, an adjustment is made >> when the initial event was created while DST was off and the current event >> is taking place with DST on. >> >> Without DST in Europe and North America, the event occurs at 10 UTC = 11 in >> Paris. >> With DST in North America and in Europe, the event occurs at 10 + 2 -1 = 11. >> With DST in North America, but not Europe, the event should occur at 10 +1 >> but instead occurs at 10 +2. >> >> It is as if dtcm was using the North American rule to determine whether DST >> is on or off, but used the European rule to decide whether >> the extra hour must be substracted. >> >> I have also found some problems with DST in dtcm have been previously >> reported on Tru64 UNIX. >> >> http://article.gmane.org/gmane.os.tru64.managers/3863 >> http://article.gmane.org/gmane.os.tru64.managers/3866 >> >> >> >> Edmond Orignac >> <march2016.png><october2016.png>------------------------------------------------------------------------------ >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140_______________________________________________ >> cdesktopenv-devel mailing list >> cdesktopenv-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel > > ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
