Calendar:Feature Implementations:Timezones

Timezone Backend Design (DRAFT)

Discussion in mozilla.dev.apps.calendar and/or the talk page here

In general, when we read in calendars, we'll get VTIMEZONEs that fall into two categories: ones that are builtin to our implementation, and foreign timezones. Authoritatively, we'll store these in single files, each containing a single VTIMEZONE, but they'll be cached in and used from SQLite databases (we may choose not to ship the directory tree version of the builtin timezones, since that just adds unnecessary download size).

When we read in calendars (or are given new VCOMPONENTS like VEVENTS or VTODOS),there will be a number of different types of TZIDs that we'll find:

• Starts with /mozilla.org/current_dtstamp/
  • The current internal database version
  • Nothing to do here
  • Raw path: installdir/timezones/current_dtstamp/Continent/City.ics
  • DB path: installdir/timezones/current_dtstamp/builtin-zones.sqlite3

• Starts with /mozilla.org/older_dtstamp/
  • An older internal version
  • Change reference to current version
  • Raw path, DB path: (none, see current version)

• Starts with /mozilla.org/newer_dtstamp/
  • treat as any other globally unique zone (see below)

• Other
  • DB path: profiledir/timezones/imported-zones.sqlite3
  • Starts with /
    • Claims to be globally unique
    • Not in database? Add it.
    • Already in database? Compare...
      • ==, nothing to do
      • !=, reject (in the future, we could rename)
    • Raw path: profiledir/timezones/prettified_name
  • Does not start with a /
    • Assign a UUID for tracking
    • Raw path: profiledir/timezones/uuid

Still to sort out:

• XXX for added zones, how do we manage the lifetimes? Refcount or GC-by-occasional-rebuild?
• XXX mapping of foreign timezones for UI display
• XXX What about fork or deletion of timezones?
• XXX updating of the builtin database (maybe put in profiledir and mark installdir zones obsolete, given root perm issues)
• XXX filename/TZID/UUID mappings