[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Date/time class changes to handle extended date ranges
From:       "R.F. Pels" <ruurd () tiscali ! nl>
Date:       2006-02-21 0:23:07
Message-ID: 200602210123.09177.ruurd () tiscali ! nl
[Download RAW message or body]

On Tuesday 21 February 2006 00.40, Frans Englich wrote:

>> These do not necessarily have to be added to QDate, correct? I mean, this
>> could also be part of a connector of some sorts? OTOH, it would be a
>> shame not to make use of datestring parsing already contained in QDate.
>> Hmmm. A QDate /does/ already know how to parse date strings, so adding
>> parsing for xs:date actually does not violate the mandate of QDate.
>
> Nothing of what I wrote /has/ to be in Qt, except for the extended QDate
> range. However, if you want to create a QDate from a string representation
> of xs:date you must either manually write code for it or extend QDate. It
> depends on how much "out of the box" you want Qt to be for WXS types.

Sorry about that, was merely braindumping... something along the lines of 
thinking about string-to-object conversions belonging to the interface of the 
class converted to or not and then in the middle of that thought realizing 
QDate already does have that included as a method and that representing a 
date as a string or interpreting a string as a date has a lot to do with the 
concept of date in general. No matter. These types of things have a habit of 
flashing through my mind now and again.

> But you are right, it wouldn't be a big change; extending it to parse
> xs:date would be like an accent of Qt::ISODate.

I agree. As is adding the necessary methods to QByteArray and QUrl etcetera. I 
would be quite happy if that was added to Qt...

-- 
R.F. Pels,  3e Rompert 118,  5233 AL  's-Hertogenbosch,  The Netherlands
+31736414590        ruurd@tiscali.nl       http://home.tiscali.nl/~ruurd

[prev in list] [next in list] [prev in thread] [next in thread]