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. 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. 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. 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? Cheers! John. _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
