Re: Fw: Fwd: [Qt bugreports] Updates for QTBUG-75585: Massive performance regression in QML Date object

> Negative values are ok, so 1926 wouldn't be a a problem. And modern
> implementations even work after 2038, so this would'nt be a problem
> either.

You're right, but still, readability of the XML file has always been important
for KPA. So I think we really should stick to the ISO 8601 dates.

> > As always, I would love to see the database format stable - especially
> > when importing / exporting image sets via *.kim.
>
> That's an important point. But IMHO it need's not to be stable but
> backward compatible. If we could just add information old implementations
> could still work with it.

Please notice that any compatibility problem only can arise if you open your
db with a new version of KPA so that it's updated and then downgrade KPA
again.

And in this case, if we dot it like I would propose it, the only inconvenience
would be that the times may be displayed in UTC. I'm not sure about this
though, I didn't look at the displaying code yet. Even older versions of KPA
should correctly parse the newly added timezone.