Op 25-8-2011 8:56, lars.kn...@nokia.com schreef:
On 8/24/11 7:06 PM, ext John Laytjl...@kde.org 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
