Op 25-8-2011 8:56, [email protected] schreef: > On 8/24/11 7:06 PM, "ext John Layt"<[email protected]> wrote: > >> On Wednesday 24 Aug 2011 07:35:33 Andre Somers wrote: >> >>> I hope you don't mind me pitching in at this point? >>> I am wondering what the plans are with those then. We use them heavily >>> in our QTimeSpan MR, >>> and as discussed at QtCS and remarked elsewhere before, I was even >>> planning to add some >>> of the date math used there to QDateTime as well (and then use that >>> implementation, obviously). >>> Would these become features of the QCalendarSystem then? >>> >>> André >> Well, while the routines I currently use in KDE for date maths are >> completely >> generic, i.e. none of them so far have needed special handling varying by >> calendar system, I can't guarantee this will always be the case. I >> suspect >> Hebrew has special cases that I don't yet know about, given it has leap >> months >> inserted in the middle of the year. It's also very different adding 1 >> Gregorian year and 1 Islamic year, so any new maths functions should go >> in the >> Calendar and any new TimeSpan class really should use the new api and >> thus the >> system calendar, with it well documented that if you specifically need >> Gregorian then you must explicitly set to do so. For me as a simple programmer, it does not make much sense to have to deal with calendars, dates, and locales in order to do something useful with a date. Please don't complicate the simple usecases too much. The locale will have the current calendar to use. So, why not have the operators on the classes themselves simply use the applications locale, and only force the users to explicitly use the calendars (and the locale) if they want to do something none-trivial. > The whole QTimeSpan piece makes me wonder. QTimeSpan is bound to the > gregorian calendar currently. It feels odd introducing this class with > that limitation. I agree with that, that's why I brought it up in the discussion. > What I wonder about is whether date arithmetics don't belong into the > QCalendar(System) class. They are logically bound to it anyway. That could indeed be the best place to actually implement them, but please keep them accessible from the data/time classes. Just note in the docs that their results depend on the currently set calendar in the current application locale. > >> I see also in the other thread you mention you have a Qt::TimeUnit enum, >> well >> I'm planning a new DateTimeField enum in one of the Qt/QLocale/QDateTime >> namespaces to match the CLDR date/time fields. This would be used in the >> date/time parser and formatter classes and the widgets. This would also >> include things like Years, Weeks, Minutes, Seconds, etc so we'll need to >> coordinate to make sure we don't clash there, or possibly share the same >> enum. > Exactly the reason I once commented on the merge request that I don't like > the TimeUnit enum in the Qt namespace. The enum values are too generic to > not likely clash with something else at some point. This I don't understand. I think that is a similar enum is needed at more places in Qt, it would make _perfect_ sense have the enum in the Qt namespace. I would find it weird to see very similar enums in the different time/date related classes, and not have them be compatible. Note that I tried to discuss this topic with you via de comments on the MR, but I did not hear back on my reaction on your comment in the MR. >> Note also that CLDR defines support for correctly localising strings for >> plurals like "1 day" and "3 days", and also supports localised Interval >> Formats. We will have to look at using that in QTimeSpan, and move the >> QTimeSpan toString() and fromString() into QLocale to keep with the >> pattern of >> QLocale being the only place to get user visible strings. Well, if the CDLR defines that, then it would probably make sense to use it. However, I think we should not throw away the option to just define the format yourself, as it is done now.
I have doubts however on using QLocale for every string. I think it is not very intuitive to _have_ to use another class than the class you currently just to get a formatted string. I would prefer to have these methods on the relevant classes as well, and have them use the locale currently set for the application. If you want to use a specific local, then it makes sense to have to use QLocale directly, but otherwise, I would not like to be bothered with that class all the time. >> I should probably start a spearate thread for this, but do you see the >> need >> for a separate QDuration in addition to QTimeSpan? By that I mean a very >> lightweight class that has no knowledge of date or timezone or absolute >> start >> point, just stores H:M:S.ms, sort of like a QTime compared to QDateTime. >> In >> fact the easiest way would just be to have a flag to set on QTime that >> changes >> whether the object enforces the 00-23 hour range or allows any hour >> value. >> That could be slightly confusing or may have unfortunate side-effects, so >> perhaps a separate QDuration is better? Or do you think QTimeSpan is >> light >> enough for that scenario as well? No. I don't. I really do not see the point. I think it will result in confusion. We discussed that recently with the merge request. I do not see the QDateTime that is stored in the QTimeSpan as a big issue. It is not like we are likely to handle them in huge quantities. I think the functionality is too closely related to separate into two classes, even if we are in principle dealing with two separate concepts. > It feels like we need to rethink QTimeSpan and interaction with the > calendar a bit before we move forward. If the class is purely bound to > gregorian it feels wrong given that we get the other calendaring systems > as well. ACK. _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
