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 single-file 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/
  • 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 How do we do updating of the builtin database?