[Qt-interest] New Date and Time Features in Qt5?

[Konrad Rosenbaum]

On Saturday 14 May 2011, Thiago Macieira wrote:
> On Friday, 13 de May de 2011 19:40:15 Dan White wrote:
> > May I help ?
> > It would be easy to put in Unix/Linux/MacOS systems, but I do not know
> > Windows enough to know how to integrate it.
> 
> You can help. But we'll need someone to do the Windows parts too.

If the decision is to base everything on Olson DB, then adding Windows is 
fairly easy: 

1) you have to include at least large parts of the time zone files - that is 
1.9MB of unpacked data, about 300kB if zipped in a resource file.

2) you have to provide a mapping between Windows time zone names and Olson 
names - mappings are out there (google helps), they are fairly easy for 
Windows to Olson, but the other way around may be hard to do (there are far 
more Olson TZs than Windows TZs)

There are dangers involved of course:

Windows may change TZ names or add new ones. In that case the affected TZs 
have no valid mapping and an Olson based application will fail to show the 
correct time in more cases than just the obvious ones!

Some TZ definitions may be subtly different between Windows and Olson - as I 
noted in another mail governments tend to change definitions from time to 
time - there is a small gap between the time that each definition is updated 
during which the time calculations of the application and the system will 
have very different opinions about the local time - not even talking about 
the case that an old legacy application runs with a hopelessly outdated 
Olson DB built in.


From my experience with implementing Olson support on top of Qt4: the sanest 
approach is to define QDateTime as an interface between Qt and the NATIVE 
clock of the system - no advanced time zone support, no leap seconds, no 
fancy stuff. Then implement another module (this is at least 4 classes, not 
just one) to represent time zone calculations. The only enhancement that 
QDateTime itself needs in this scenario is to be able to carry some meta 
data (an "I'm not native" bit, an offset from UTC for this particular time 
stamp and some info to identify the time zone like an Olson DB TZ name).

This approach would also make it feasible to program more modules with each 
supporting a different style of calculating time. If you try to push all of 
them into QDateTime then your interfaces and test cases explode to the point 
of being unmanageable.


	Konrad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20110515/49b604d1/attachment.bin