[PATCH] Extend KDateTime with a fancyString()

[Tom Albers]

Hi David,

Op vr 6 apr 2007 13:42 schreef u:
> On Thursday 05 April 2007 20:44:28 David Jarvie wrote:
> > 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. 

I really don't have a clue about handling those things. The / my problem lies in the fact that I'm getting a KDateTime from kmime and I need to go to the fancy date from there. The dateformatter in KMime does not accept the KDateTime, so I'm converting it now all over the place, just to get the fancy date. 

As that routine is pretty time critical (although the model/view setup makes it a bit less critical for me). I wanted to prevent those conversions and add it to KDateTime. I only extracted the code from dateFormatter, so I can not comment on the errors in the code.

> >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.
> 
> I've been thinking further about this, and now see two preferable approaches:
> 
> The function may (in its current form) belong better in KLocale. It's really a 
> modified form of KLocale::formatDateTime() where sometimes the date part is 
> substituted by a word representing the day, although if we want to do the day 
> substitution on the basis of the time zone of the specified date/time 
> instance (rather than the user's time zone), it would need to take a 
> KDateTime parameter rather than QDateTime.

Makes sense to me.

> Alternatively, or additionally, it could be fitted into 
> KDateTime::toString(const QString& format), with additional codes being 
> introduced to output the date or date/time formatted according to locale, 
> with fancy and short options. This would allow proper use to be made of the 
> KDateTime value by enabling time zones etc. to be included in the output 
> string, or not, as desired.

Do you want to take care of it or do you prefer me to look at it later on? I don't feel really comfortable in the code, but I can spend more time on it if you don't want to. 

Toma