Skip to content

Properly handle timezones and user’s preferred date format in bundles

Karl Ove Hufthammer requested to merge (removed):timezone-and-userpref-aware-datetimes-in-bundles into master

Before: The ‘created’ and ‘updated’ times were stored as datetimes in the author’s time zone, but without a time zone marker. If a different user had a different time zone, the time displayed would be wrong (e.g., it could be a datetime in the future). Also, the format of the displayed time was a strange mix of locale-aware stuff (e.g. localised month names) and non-locale aware stuff (the order of the different components in the datetime).

Now: The times are always stored as UTC datetimes, with an explicit datetime marker (‘Z’). (So no information about the author’s location is leaked.) They are always shown in the user’s preferred short datetime format (and in the user’s time zone).

The above is true for ‘created’ and ‘updated’ times stored as actual datetimes. Older versions of Krita only stored the date, and in the fixed ‘dd/mm/yyyy’ format. For these bundles, the date is displayed in the user’s preferred short date (not datetime) format.

Test Plan

  1. Open the resource manager. Check the ‘Created:’ and ‘Updated:’ time for older bundles. They should be displayed as dates in your preferred date format.
  2. Create a new bundle. Update it. Check the ‘Created:’ and ‘Updated:’ time for the new bundle. They should be displayed as date + time in your preferred format (and correspond local time).
  3. Restart Krita and repeat step 2.
  4. Open the stored bundle file (which is just a .zip file) and examine that in the file meta.xml, the meta:creation-date and meta:dc-date elements have the correct (UTC) times, with ‘Z’ as the timezone marker (example: 2019-08-02T12:07:55Z).

Formalities Checklist

  • I confirmed this builds.
  • I confirmed Krita ran and the relevant functions work.
  • I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
  • I made sure my commits build individually and have good descriptions as per KDE guidelines.
  • I made sure my code conforms to the standards set in the HACKING file.
  • I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.

Merge request reports