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.
The whole QTimeSpan piece makes me wonder. QTimeSpan is bound to the gregorian calendar currently. It feels odd introducing this class with that limitation. What I wonder about is whether date arithmetics don't belong into the QCalendar(System) class. They are logically bound to it anyway. > >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. > >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. Yes, agree with this. > >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? 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. Cheers, Lars _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
