User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.7) Gecko/20070924 BonEcho/2.0.0.7 Build Identifier: Since beginning of the year (in fact Dec 30th of last year), time zone in Argentina has been modified by one hour, and (though I'm not sure this was at the same moment) the denominations for time zones in Argentina changed. Argentina is now specified as America/Argentina/<city> according to the official timezone database. So, for example, what was America/Cordoba is now America/Argentina/Cordoba. Wouldn't it be more logical to take the table from the table in the machine, instead of adding another table to maintain? Now I have the 'official' table in /usr/share/zoneinfo, another table in PHP, and now _another_ table in Orage? Also, I haven't found a way yet to check which value of GMT offset is activated by selecting /America/Cordoba in Orage, but I suspect it's -0300, which is incorrect. I suggest you show the value selected numerically too. Sidebar: I would suggest a LARGE advisory on compilation/before install that the original data will be lost (just lost mine) Reproducible: Always Steps to Reproduce: 1.Set timezone 2. 3. Actual Results: America/Cordoba (Can't check, but suspect -0300 ART) Expected Results: America/Argentina/Cordoba (Should be -0200 ARST) /usr/share/zoneinfo was updated and date shows: Wed Feb 6 13:14:18 ARST 2008 date +"%z %Z" gives -0200 ARST
Sorry - also I'd suggest to take the link /etc/localtime-copied-from (which links to /usr/share/zoneinfo/America/Argentina/Cordoba) as a suggestion for the default value of the time zone.
Yep, I would love to take the times from operating system, but I do not know how to convert from he machine zoneinfo to ical zoneinfo. Not simple. Seems like I need to try harder, since it is impossible to keep up with the changes. (Note that orageclock and globaltime already use os time and should show this correctly. The problem is only in Orage.) I like also the feedback idea of timezone data. The original data is not actually lost. The new version 4.5 uses different default location for its data. You can either change to the old or export the old data. Old default location: ~/.config/xfce/orage/orage.ics New default location: ~/.local/share/orage/orage.ics /etc/locatime is not 100% reliable, but agree, it works in most distroes. Thanks for a very nice set of bugs/enhancement. I'll see what I can for those.
Thanks for replying so soon... I was a little worried as I didn't see any other bug reports on the system. If there's anything I can do to help? I'm no great programmer, but maybe I _can_ help somewhere. I'd like to suggest two another (probably simpler) enhancements: * Aesthetically: Don't open the bottom part of the calender unless there's something to show. When Orage pops up, it'd look nicer that way. * A way to paint the dates differently, according the event (maybe the background?). Say, choose a color when defining the event. That way I don't have to consult each event to know what it was. This would be great for another reason: With normal system font (Sans?) the 'Bold' isn't all that different from the normal weight. Hey, sorry, I'm just loading more weight onto you shoulders, ;-) John BTW: Why does it take so long to mark the date when switching months? I estimate it takes about 1/2 second or more, and there are only 8 items in the database... I don't think it's the machine (AMD-64)
fixed component. The 0,5 sec delay in marking the days in the calendar is due to fixing bug 2080.
Hide bottom box when it is empty in version 4.5.12.5-svn (revision 26602)
Argentina timezones fixed in Orage 4.5.12.9 (revision 26613). The other things discussed in this BUG are in progress, but the real BUG is now fixed. The rest is enhancements.
I set this as duplicate of 3990, which is the real fix for this. *** This bug has been marked as a duplicate of bug 3990 ***
in 4.8.0