Calendar:Feature Implementations:Timezones - Revision history

Ctalbert at 22:45, 19 August 2007

2007-08-19T22:45:15Z

← Older revision		Revision as of 22:45, 19 August 2007
Line 14:		Line 14:
	<pre>		<pre>
	AddTimezone(in string Tzid,		AddTimezone(in string Tzid,
	in ~~string icalString of~~ timezone data to add,		in calIIcalComponent timezone data to add,
			in string latitude,
			in string longitude,
			in string stdOffset,
	out TimezoneEntry of timezone added/found)		out TimezoneEntry of timezone added/found)
	</pre>		</pre>

Ctalbert at 22:09, 19 August 2007

2007-08-19T22:09:34Z

← Older revision		Revision as of 22:09, 19 August 2007
Line 5:		Line 5:
	<i> Discussion in mozilla.dev.apps.calendar</i>		<i> Discussion in mozilla.dev.apps.calendar</i>

	<i> "To understand timezones, it really, really helps to be drunk." Stephen Mook</i>		<i> "To understand timezones, it really, really helps to be drunk." -- Stephen Mook</i>

	So, here we are for round three. We are thinking to use an extension to manage the timezone database since the general database server (as discussed below) is not looking to happen any time soon. So, in order to do this in an extension, we need to stub in an interface that the extension can then implement. This interface will be the calITimezoneResolver. Providers that use server stored timezones which are different from the Olsen timezone database (I'm looking at you, Outlook), can implement this interface also and provide their own timezone definitions.		So, here we are for round three. We are thinking to use an extension to manage the timezone database since the general database server (as discussed below) is not looking to happen any time soon. So, in order to do this in an extension, we need to stub in an interface that the extension can then implement. This interface will be the calITimezoneResolver. Providers that use server stored timezones which are different from the Olsen timezone database (I'm looking at you, Outlook), can implement this interface also and provide their own timezone definitions.
Line 12:		Line 12:

	calITimezoneResolver:		calITimezoneResolver:
	* AddTimezone(in string Tzid,		<pre>
	in string icalString of timezone data to add,		AddTimezone(in string Tzid,
	out TimezoneEntry of timezone added/found)		in string icalString of timezone data to add,
	** Attempts to find this Tzid in the timezone database and if it is found, returns successfully and returns the timezone found		out TimezoneEntry of timezone added/found)
	** If the Tzid is not found in the database, then this adds the timezone to the database, and returns the timezone added		</pre>
	* GetTimezone(in string Tzid,		* Attempts to find this Tzid in the timezone database and if it is found, returns successfully and returns the timezone found
	out TimezoneEntry of timezone found/null if not found)		* If the Tzid is not found in the database, then this adds the timezone to the database, and returns the timezone added
	** Finds the timezone with the matching tzid in the database		<pre>GetTimezone(in string Tzid,
	* GetTimezoneList(out An nsIUTF8StringEnumerator of all Tzid's in the database)		out TimezoneEntry of timezone found/null if not found)</pre>
	** Returns a string enumerator of all known tzid's in the database		* Finds the timezone with the matching tzid in the database
	* GetVersion (out string version)		<pre>GetTimezoneList(out An nsIUTF8StringEnumerator of all Tzid's in the database) </pre>
	** Returns the version of the underlying timezone datastore		* Returns a string enumerator of all known tzid's in the database
			<pre>GetVersion (out string version)</pre>
			* Returns the version of the underlying timezone datastore

	Putting the timezone database into the extension changes the nature of upgrading the timezone information from a code update into more of a build/release update. As long as the underlying database structure does not change, there should be no need to update the associated code in the extension. But, I do think it makes sense to also package the database, the TimezoneStorageService (the C++ wrapper for the database) and the calITimezoneResolver implementation together in the extension. So, that amount of code will be updated each time the timezone database is updated by the extension update mechanism.		Putting the timezone database into the extension changes the nature of upgrading the timezone information from a code update into more of a build/release update. As long as the underlying database structure does not change, there should be no need to update the associated code in the extension. But, I do think it makes sense to also package the database, the TimezoneStorageService (the C++ wrapper for the database) and the calITimezoneResolver implementation together in the extension. So, that amount of code will be updated each time the timezone database is updated by the extension update mechanism.

Ctalbert at 22:07, 19 August 2007

2007-08-19T22:07:30Z

@@ Line 1: / Line 1: @@
 [[Calendar:Feature_Implementations| <<Back to Features]]
-= Timezone Backend Design (DRAFT) =
+= Timezone Backend Design (DRAFT) v3 =
 <i>Discussion in mozilla.dev.apps.calendar</i>

Pluk77 at 13:04, 12 July 2007

2007-07-12T13:04:53Z

← Older revision		Revision as of 13:04, 12 July 2007
Line 1:		Line 1:
			[[Calendar:Feature_Implementations\| <<Back to Features]]

	= Timezone Backend Design (DRAFT) =		= Timezone Backend Design (DRAFT) =

Line 76:		Line 78:
	* {{bug\|314339}} – need to handle non-native timezone bits		* {{bug\|314339}} – need to handle non-native timezone bits
	* {{bug\|363191}} - Handle Timezones more efficiently (Timezone Database)		* {{bug\|363191}} - Handle Timezones more efficiently (Timezone Database)

			[[category:calendar\|Timezones]]

Ctalbert: /* Timezone Backend Design (DRAFT) */

2007-02-21T18:20:35Z

Timezone Backend Design (DRAFT)

← Older revision		Revision as of 18:20, 21 February 2007
Line 1:		Line 1:
	== Timezone Backend Design (DRAFT) ==		= Timezone Backend Design (DRAFT) =

	<i>Discussion in mozilla.dev.apps.calendar ~~and/or the talk page here~~</i>		<i>Discussion in mozilla.dev.apps.calendar</i>

	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).		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:		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. Below, I will use "Foreign" timezone to refer to a zone that was not created by the current or previous version of the currently running Sunbird/Lightning. For example, if a user on 0.3.1 receives an event from 0.5, that would be handled as a "Foreign" timezone. However, if that user receives an event with a 0.3 timezone definition, that would NOT be a "Foreign timezone". Each of these timezone types will be dealt with according to the list below:

			'''Current Mozilla Timezones'''
	* Starts with /mozilla.org/current_dtstamp/		* Starts with /mozilla.org/current_dtstamp/
	** The current internal database version		** The current internal database version
Line 13:		Line 14:
	** DB path: installdir/timezones/current_dtstamp/builtin-zones.sqlite3		** DB path: installdir/timezones/current_dtstamp/builtin-zones.sqlite3

			'''Older Mozilla Timezones'''
	* Starts with /mozilla.org/older_dtstamp/		* Starts with /mozilla.org/older_dtstamp/
	** An older internal version		** An older internal version
Line 18:		Line 20:
	** Raw path, DB path: (none, see current version)		** Raw path, DB path: (none, see current version)

			'''Newer Mozilla Timezones'''
	* Starts with /mozilla.org/newer_dtstamp/		* Starts with /mozilla.org/newer_dtstamp/
	** treat as any other globally unique zone (see below)		** treat as any other globally unique zone (see below)

			'''Foreign Zones -- Timezones from other applications (including newer Mozilla zones)'''
	* Other		* Other
	** DB path: profiledir/timezones/imported-zones.sqlite3		** DB path: profiledir/timezones/imported-zones.sqlite3
	**		**
	** ~~Starts with /~~		** Assign a UUID for tracking
	*** Claims to be globally unique		*** Claims to be globally unique
	*** Not in database? Add it.		*** Not in "foreign timezone database"? Add it.
	*** Already in database? Compare...		*** Already in database? Compare...
	**** ==, nothing to do		**** ==, nothing to do
	**** !=, reject (in the future, we could rename)		**** !=, reject (in the future, we could rename)
	*** Raw path: profiledir/timezones/~~prettified_name~~		*** Raw path: profiledir/timezones/uuid/
	** Does not start with a /
	*** Assign a UUID for tracking
	*** Raw path: profiledir/timezones/~~uuid~~

	~~Still~~ to ~~sort out:~~		==Other Issues==
	* ~~XXX~~ for ~~added~~ zones, ~~how~~ do we ~~manage~~ the ~~lifetimes?~~ ~~Refcount~~ or GC-by-~~occasional~~-~~rebuild?~~		===Foreign Zone Lifetime===
	* ~~XXX mapping of~~ foreign timezones ~~for UI display~~		Until there is a reliable "standard" copy of timezone definitions available from a server side timezone database, we will need to maintain non-Sunbird/Lightning timezones. Once there is a standard copy of timezone definitions that we can depend on to be current, we can consider merging "foreign" timezones into the standard copy, and we may not need to keep copies of those zones. In the meantime, I propose that we use a refcounting scheme in order to manage the lifetime of the foreign timezone definitions.
	* ~~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~~)		* Use refcounts to manage the lifetime of a all zones (including the built-in ones, this is useful for updating our definitions).
	* ~~XXX filename~~/~~TZID~~/~~UUID mappings~~		** Once the number of events referencing that zone goes to zero, we remove that zone from the database
			** Should these refcounts be maintained in the flat file copy of the timezone? I'm not sure, it depends on the function of the flat files (see TODO's below)
			** Each event that references this foreign zone will add one to the zone's refcount. When the event is deleted (an entire event -- not an instance of an appointment is deleted) then the refcount will be decremented by 1.

			===Displaying Foreign Timezones===
			* Users will NOT be able to create events using foreign zones.
			* Users will be able to edit a VEVENT or VTODO that contains a Foreign timezone reference without disturbing the timezone reference (unless the user edits the timezone specification, of course).
			* Users will be able to view a foreign timezone in our timezone picker.
			** We will do this by displaying the TZID in text
			** If we have a graphical picker, we will highlight the proper zone offset, so that the user can see geographically where the zone lies.
			** (Enhancement) If needed, we may be able to map the zone using the TZID to our set of known zones so that a proper city location can be displayed to the user. In most cases we can do this because by convention TZID's will usually contain enough descriptive text for us to establish a linkage with our own city list from our internal zones. Of course, should this not be possible for the given TZID, then we will have to forgo this level of mapping and will have to rely instead on showing the user the TZID and the UTC offset.

			===Updating timezone Definitions===
			* Updating Built-in Timezones
			* All timezones in database will have a new TZID field. This will be blank until an update occurs. When the update occurs, the field will be populated with a key referencing the new TZID, and the subsystem will use this new key to map the old timezone definition to the updated timezone defnition.
			* When updating, foreign timezones will be left alone. They will not be updated or destroyed. (When there is a standard timezone database service, we will revisit this.)
			* When a VEVENT or VTODO performs a lookup on an old timezone definition, the newer definition will be returned, and the refcounts will be handled as follows:
			*** Old timezone defintion refcount-- (if this is 0 we will remove the old definition)
			*** New timezone definition refcount++

			===Timezone Mappings between Builtin zones and Foreign Zones===
			* While there is no standard for timezone mappings, there are conventions
			* Other implementations that use the Olson database should be fairly trivial to map, we simply compare the offsets then the continent, then the city.
			* The other primary convention we will find will be the Windows timezone naming system, which can be [http://www.chronos-st.org/Windows-to-Olson.html mapped to Olson].
			* In order to map between the flat file store and the database store for the foreign timezones, it would be fairly simple to have a path descriptor and/or filename (since we know it will live in the Profile Dir) in the database. Then the timezone service can simply query the database to find the file information and use that. TODO: Should the database be able to operate using only a flat-file system?

			==TODO==
			* What problems does the flat file system solve? What does it gain over the database, or is it simply a handy backup?
			* Do we need a user accessible backup utility, perhaps something that will dump all the timezone definitions (builtin and foreign) to a set of flat files?
			* How much user control do users exercise over the timezone database? Is there/should there be an "Update Timezone Definitions" button in prefs somewhere?
			* Is there a cost to using a different database for foreign zones vs. builtin zones? Would it make comparisons simpler/more performant to use the same sqlite database for both sets of timezones? I tend to think we should use the same database for both, is there some valid reason to not do this?

	References:		References:
	* {{bug\|314339}} – need to handle non-native timezone bits		* {{bug\|314339}} – need to handle non-native timezone bits
	* {{bug\|363191}} - Handle Timezones more efficiently (Timezone Database)		* {{bug\|363191}} - Handle Timezones more efficiently (Timezone Database)

Ssitter: reference to existing bugs

2007-01-19T22:10:23Z

reference to existing bugs

← Older revision		Revision as of 22:10, 19 January 2007
Line 41:		Line 41:
	* XXX updating of the builtin database (maybe put in profiledir and mark installdir zones obsolete, given root perm issues)		* XXX updating of the builtin database (maybe put in profiledir and mark installdir zones obsolete, given root perm issues)
	* XXX filename/TZID/UUID mappings		* XXX filename/TZID/UUID mappings

			References:
			* {{bug\|314339}} – need to handle non-native timezone bits
			* {{bug\|363191}} - Handle Timezones more efficiently (Timezone Database)

Dmose: /* Timezone Backend Design (DRAFT) */

2007-01-17T23:45:42Z

Timezone Backend Design (DRAFT)

← Older revision		Revision as of 23:45, 17 January 2007
Line 3:		Line 3:
	<i>Discussion in mozilla.dev.apps.calendar and/or the talk page here</i>		<i>Discussion in mozilla.dev.apps.calendar and/or the talk page here</i>

	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.		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:		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:
Line 10:		Line 10:
	** The current internal database version		** The current internal database version
	** Nothing to do here		** Nothing to do here
	** Raw path: installdir/timezones/current_dtstamp/		** Raw path: installdir/timezones/current_dtstamp/Continent/City.ics
	** DB path: installdir/timezones/current_dtstamp/builtin-zones.sqlite3		** DB path: installdir/timezones/current_dtstamp/builtin-zones.sqlite3

Line 39:		Line 39:
	* XXX mapping of foreign timezones for UI display		* XXX mapping of foreign timezones for UI display
	* XXX What about fork or deletion of timezones?		* XXX What about fork or deletion of timezones?
	* XXX ~~How do we do~~ updating of the builtin database?		* XXX updating of the builtin database (maybe put in profiledir and mark installdir zones obsolete, given root perm issues)
			* XXX filename/TZID/UUID mappings

Dmose at 23:40, 17 January 2007

2007-01-17T23:40:30Z

New page

== Timezone Backend Design (DRAFT) ==

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

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?