Changes between Initial Version and Version 1 of BluePrintTimezones


Ignore:
Timestamp:
12/15/09 11:34:55 (12 years ago)
Author:
Dominic König
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrintTimezones

    v1 v1  
     1= Handling of Timezones =
     2
     3== Original Timezone Implementation ==
     4
     5  - time zones are handled as fixed UTC offsets
     6  - the server UTC offset is an admin setting
     7  - users can set their own offset in their profile, which defaults to the server UTC offset
     8
     9  - datetime values are stored in the database as UTC
     10  - datetime values are displayed in the user's (fallback: server's) time zone using their respective UTC offset
     11  - DST doesn't get adjusted
     12
     13  - we use a custom validator IS_UTC_DATETIME() which accepts datetimes in:
     14    - ISO format without trailing UTC offset (=interpreted as being in user's local time)
     15    - extended ISO format with trailing UTC offset (=interpreted according to the trailing offset)
     16  - the validator converts datetime values on input into UTC
     17  - datetime values retrieved from the DB are converted into local time using the current user's UTC offset:
     18    - shn_user_utc_offset() retrieves the current user's UTC offset as "+/-HHmm" (fallback: server UTC offset)
     19    - shn_as_local_time() formats UTC datetimes according to the current user's UTC offset
     20    - shn_as_local_time() is used for .represent of datetime values
     21
     22== New Timezones Implementation ==
     23
     24  - time zones are handled by their abbrevated names (e.g. UTC, CET, CEST and so forth)
     25  - the server timezone is an admin setting
     26  - users can set their own timezone in their profile, which defaults to the server timezone
     27
     28  - datetime values are stored in the database as UTC
     29  - datetimes are displayed/accepted with timezone correction and automatic DST adjustment:
     30    - at input according to a fallback cascade of:
     31      * the timezone specified at the input value (if any)
     32      * the timezone specified by .requires of the respective field (if any)
     33      * the current user's timezone
     34    - at output according to a fallback cascade of:
     35      * the timezone specified by the controller at the request (use-case see below)
     36      * the timezone specified by .represent of the respective field (if any)
     37      * the current user's timezone
     38
     39  - we use a custom validator IS_UTC_DATETIME() which accepts datetimes in:
     40    - ISO format without trailing timezone or UTC offset (=interpreted as being in user's local time, automatic DST adjustment)
     41    - extended ISO format with trailing UTC offset (=interpreted according to the trailing offset, no DST adjustment)
     42    - extended ISO format with trailing timezone (=interpreted according to the trailing timezone, automatic DST adjustment)
     43
     44=== Special use-cases ===
     45  - where information is to be saved about the timezone of the entering user, this should happen in an extra field
     46  - when information is stored about the timezone of the entering user, the datetimes should be displayed in that timezone instead of the reading user's local time, clearly indicating to the reading user which timezone the datetime is expressed in
     47
     48=== Automatic DST adjustment ===
     49
     50  ''dst_adjustment = function(datetime, timezone)''
     51
     52Meaning: DST adjustment depends on the respective timezone '''''and''''' the datetime value (!)
     53
     54e.g., with the user's timezone being CET:
     55   - 2009-07-03 14:33 is interpreted as 2009-07-03 12:33 UTC (offset +02:00), while
     56   - 2009-11-08 18:15 is interpreted as 2009-11-08 17:15 UTC (offset +01:00)