Changes between Version 2 and Version 3 of BluePrintTimezones


Ignore:
Timestamp:
10/21/10 06:38:49 (14 years ago)
Author:
Fran Boon
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrintTimezones

    v2 v3  
    2222== New Timezones Implementation ==
    2323
    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
     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  * see attachment for potential UI
    2728
    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
     29 - datetime values are stored in the database as UTC
     30 - datetimes are displayed/accepted with timezone correction and automatic DST adjustment:
     31  - at input according to a fallback cascade of:
     32   * the timezone specified at the input value (if any)
     33   * the timezone specified by .requires of the respective field (if any)
     34   * the current user's timezone
     35  - at output according to a fallback cascade of:
     36   * the timezone specified by the controller at the request (use-case see below)
     37   * the timezone specified by .represent of the respective field (if any)
     38   * the current user's timezone
    3839
    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)
     40 - we use a custom validator IS_UTC_DATETIME() which accepts datetimes in:
     41  - ISO format without trailing timezone or UTC offset (=interpreted as being in user's local time, automatic DST adjustment)
     42  - extended ISO format with trailing UTC offset (=interpreted according to the trailing offset, no DST adjustment)
     43  - extended ISO format with trailing timezone (=interpreted according to the trailing timezone, automatic DST adjustment)
    4344
    44   - Should use [http://pypi.python.org/pypi/pytz/ PyTZ] library to ensure that we don't need to maintain our own database
    45     - may use higher-level [http://blog.twinapex.fi/2008/06/30/relativity-of-time-shortcomings-in-python-datetime-and-workaround/ fixed_datetime.py] to interface with this
     45 - Should use [http://pypi.python.org/pypi/pytz/ PyTZ] library to ensure that we don't need to maintain our own database
     46  - may use higher-level [http://blog.twinapex.fi/2008/06/30/relativity-of-time-shortcomings-in-python-datetime-and-workaround/ fixed_datetime.py] to interface with this
    4647
    4748=== Special use-cases ===