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
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.

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.

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.

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

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.

-- 
David Jarvie.
KAlarm author & maintainer.
http://www.astrojar.org.uk/kalarm