PATCH: time-only support for KDateTime (used in Nepomuk-KDE)

[Sebastian Trüg]

On Thursday 15 March 2007 14:12:40 David Jarvie wrote:
> On Thursday 15 March 2007 12:02, Sebastian Trüg wrote:
> > Hi folks,
> >
> > Aaron asked me if KDateTime already provided the date and time conversion
> > functionality from KMetaData::DateTime. Actually the ISO8601 support in
> > KDateTime is nearly perfect. The only thing missing is the support for
> > time-only instances and parsing of date- and time-only strings like
> >
> > YYYY-MM-DD
> >
> > the attached patch does that. However, it breaks one unit test: with my
> > patch
> > KDateTime does create date-only ISO8601 strings like the one above which
> > is
> > perfectly valid as far as I understood ISO8601. The current
> > implementation appends the SOD time (00:00:00.000) to a date-only string.
> > This would not be
> > that big a problem for Nepomuk-KDE but just a little ugly IMHO.
>
> I did wonder when writing KDateTime whether time-only values should be
> included, and evidently they should after all. :)
>
> I won't be able to try it out until the weekend, but AFAICR date-only
> strings like YYYY-MM-DD *are* handled, provided no time zone or time

well, they are not parsed without my patch.

> offset is specified. My reading of ISO8601 is that if a time zone
> specification/offset is included in the string, a time value must also be
> included. That's why a time of 00:00:00 is appended to the date for a
> date-only value except when it's ClockTime. Unless I've misunderstood the
> standard, I don't think your change is correct.

hmm, I don't really get the use of a timezone for a date-only instance anyway.
Anyway, that would mean that I just have to use ClockTime date-only instances 
in Nepomuk-KDE. That seems reasonable.
I attached a new patch that changes it back to the original behaviour.

> I'm doubtful about the treatment of time-only values which have a TimeZone
> time specification. Without an associated date, a time value is ambiguous
> if a time zone is applied. (Time zones can adjust the meaning of a time by
> up to 2 hours depending on the date in the year. And the meaning is even
> more ambiguous for years before or after the validity of the time zone
> data.) Because of this, I suggest that a time zone specification should be
> treated the same as ClockTime. I would still allow a time zone to be
> specified for record purposes, but it should be disregarded in
> calculations.

Why not just inform the user (via documentation) that calculations with a 
timezone can never be 100% accurate. Because there may be many situations in 
which it makes sense to have time-only values with a time-zone.

> When calculations are performed on time-only values, the result should
> always be either a time-only value or invalid. AFAICS, the necessary mods
> to the code to achieve this haven't been done. For example, in
> KDateTime::addSecs(), it doesn't look as if a time-only value is returned
> when 'this' is time-only, and if the time addition happened to wrap round
> midnight, even the date wouldn't be sot.

I fixed that and also the other addXXX methods. I hope that I did not miss 
anything. I did not write time-only unit tests yet though.

> In KDateTimePrivate::setTimeOnly(), mDt should be set using setDt() to
> ensure that 'ut' and caching members are updated properly.

done.

> In kdatetime.h, the new %f format specification should be described
> sufficiently to not need to look up an external reference to find out what
> output it produces. By all means include the reference, but also explain
> its effects.

also done. I hope an example is enough.

Cheers,
Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdatetime-timeonly.diff
Type: text/x-diff
Size: 20764 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070316/6f077fe6/attachment.diff>