[PATCH] Extend KDateTime with a fancyString()

[David Jarvie]

On Thursday 5 April 2007 17:58, Tom Albers wrote:
> I extracted the fancy date handling from kmime's date formatter and added it 
to
> KDateTime. I think it belongs to this class and not to kmime.
>
> I would appreciate if someone looked if it's ok, so I can commit. 

IMHO the function doesn't belong in KDateTime in its current form, since it's 
basically processes QDateTime values without proper regard for time zones/UTC 
offsets. There should be output options to allow time zones/UTC offsets in 
its output. I think that it should be generalised to use the KDateTime string 
formatting functions with suitable substitutions for recent dates, and allow 
for output of time zone information. It would be better to define another 
member of the TimeFormat enum to specify a fancy date/time output, and 
integrate the (modified) code into the existing toString(TimeFormat) 
function.

Some detailed comments on the code:

The way you work out the time difference from now could be simplified. Replace 
the code:

===========
    const time_t currentTime = QDateTime::currentDateTime().toTime_t();
    QDateTime dateTime;
    dateTime.setTime_t( currentTime );
    const time_t toConvert = toTime_t();
    // not more than an hour in the future
    if ( currentTime + 60 * 60 >= toConvert ) {
         time_t diff = currentTime - toConvert;
============

with:

===========
   int diff = secsTo(currentUtcDateTime());
    if (diff >= 3600)
===========

I don't think the tests for today, etc., are right. They should, I think, be 
done in the time zone of 'this' instance. In that case, the code should 
instead be:

===========
    KDateTime now = currentDateTime(timeSpec());
    int diff = secsTo(now);
    if (diff >= 3600)
===========

You don't need to check for equality of years when comparing dates - it's 
redundant. 

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