I have found the origin of the problem with dtcm. It is not caused by a bug in rpc.cmsd or the csa library but by the particular value of the TZ variable. Starting dtcm with TZ=Europe/Paris /usr/dt/bin/dtcm
does not produce the incorrect shift of the start time of the recurring event at the dates where daylight savings time are in vigor in North America but not in Europe. dtcm reports that its timezone is indeed Europe/Paris. However, starting dtcm with an undefined TZ produces the incorrect shift at the dates where DST begin or end in North America. In such case dtcm is reporting that its timezone is CET-1 CEST. I was wrongly assuming that CET-1 was identical to Europe/Paris, but at least on the particular version of Linux I am using, this is not the case for daylight savings times. In parallel, when I start dtcm_lookup in a dtterm, TZ is already set to Europe/Paris, and the problem with the DST change is not seen. But when I type TZ= dtcm_lookup -d 3/1/2016, I can reproduce the problem with the DST changes. To sum up, when dtcm is started from the front panel, it seems that its timezone is not set and the DST confusion appears. The solution to the problem is simply to set TZ=Europe/Paris in the .dtloginrc. 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
