Proposed revision to KDateTime

David Jarvie lists at
Tue Apr 25 20:26:37 BST 2006

Having started using KDateTime in earnest, I have realised that it would be 
very useful to encapsulate the time specification (i.e. whether the time is 
UTC, a time zone (and which time zone), an offset from UTC or a clock time) 
in a sub-class. This would allow time specifications to be stored, 
manipulated and passed as parameters in their own right, rather than being 
buried within KDateTime.

Since there are lots of small changes throughout the code, I'm not providing a 
patch for the changes - you can download the proposed new code in the files 
kdatetime.{h,cpp} and kdatetimetest.{h,cpp} from . Please note that one of the 
tests in kdatetimetest fails - but this appears to be due to a bug in 
KTimeZone rather than KDateTime. I'll investigate this.

The main changes are, in summary:

- Creation of KDateTime::Spec class to encapsulate the time specification. It 
includes convenience static constants and methods which provide shorthand 
access to different time specification types.

- Replacement of KDateTime constructors which take KTimeZone* or 
KDateTime::SpecType parameters with constructors which take a KDateTime::Spec 
parameter. Often, code which used the old constructors will not need to be 
changed since KDateTime::Spec constructors offers implicit conversions from 
KDateTime::SpecType and KTimeZone* . Similarly, setTimeSpec() and 
setFromStringDefault() methods' parameters are replaced by KDateTime::Spec.

- The addition of timeSpec() method to return the KDateTime::Spec for the 

- Removal of compareTimeSpec(). Replace it with timeSpec() == other.timeSpec()

Other improvements are:

- A new secsTo_long() method which returns a 'long long' for dates far apart.

- addSecs() and addMSecs() now take 'long long' arguments to handle greater 
date ranges.


David Jarvie.
KAlarm author and maintainer.

More information about the kde-core-devel mailing list