Date output needs to use KCalendarSystem in order to be properly internationalized and localized and avoid bombarding the user with meaningless date formats for their locale. (KDE 3.2+)
The user may not want to use the locale format for any number of reasons, so they are presented wih several standard options - including use of their locale.
Sure, some of them are nice to have. It could even take a formatting string and format the date based on that. However, Qt's "locale" formatting code is obviously insufficient since we created KCalendarSystem. That's the point of the bug.
On Tuesday 19 October 2004 13:05, Andrew Walker wrote: > One obvious problem is that KCalendarSystem is in KDE 3.2 and up, > whereas many people are still using KDE 3.1. What is it that > KCalendarSystem provides that Qt doesn't? (not in general, but > specific to what we are trying to do here). If we're going to go to the > trouble of ifdef'ing code then there should be a very good reason for it. There's no need to ifdef. The files are of course LGPL and self-contained. It's maybe a dozen or so including the implementations of all the different calendars. It should hook cleanly into Kst, and we just conditionally compile it if we need to the way KMDI is done. Regarding KDE 3.1, if I remember discussions long ago, were we going to prepare to move to 3.2/3.3 min requirement in the new year? What KCalendarSystem does is output the dates correctly for all KDE users. It is the most correct approach, which is why it was suggested from the start. Do we have people from these backgrounds using Kst? Certainly, our oldest bug proves that. The non-deprecated K* classes must be preferred to the Qt equivalents in Kst.
I must still be missing something here. KCalendarSystem does not (that I can see) provide a formatted string from a QDate. What it does do is return such things as the month name, day of week name, etc from a QDate. So I don't see where KCalendarSystem would be useful in this scenario as I'm not interested in anything but numeric values for day, month, etc. Qt does exactly what I want, and KCalendarSystem adds nothing to it. If you disagree please give me same example code of how KCalendarSystem could be used in this case, else I'll withdraw this bug.
On Monday 07 March 2005 17:22, Andrew Walker wrote: > ------- I must still be missing something here. KCalendarSystem does not > (that I can see) provide a formatted string from a QDate. What it does do > is return such things as the month name, day of week name, etc from a > QDate. So I don't see where KCalendarSystem would be useful in this > scenario as I'm not interested in anything but numeric values for day, > month, etc. Qt does exactly what I want, and KCalendarSystem adds nothing > to it. If you disagree please give me same example code of how > KCalendarSystem could be used in this case, else I'll withdraw this bug. Ok, I think there may have been month text code in there at one time. If it's gone, then we probably don't need KCalendarSystem. -However-, numeric formatting for dates and times still need to follow the KDE l10n settings since, for example, 03/03/05 means one of six different things depending on the location.
KCalnedarSystem does not provide the stated functionality.