Changes between Version 24 and Version 25 of SummerOfCode2010

04/04/10 20:51:37 (10 years ago)
Russell Keith-Magee

Added project outline for time zones


  • SummerOfCode2010

    v24 v25  
    153153 * [source:django/trunk/django/db/models/ The current app loading mechanism]
    154154 * Ideas on a InstalledAppsRevision collected during Pycon 2008 development sprint
     156=== Multiple timezone support for datetime representation ===
     157 * '''Complexity''': Medium
     159Currently The `TIME_ZONE` Django setting allows PostgreSQL-backed installations to run project/application on timezones different from each other and from the system timezone of the server.
     160Also, the information of !DateTime fields is retrieved from the database as naïve Python `datetime` instances and when the DB backend is PostgreSQL the data sent and retrieved to/from the DB is corrected by the `TIME_ZONE` value.
     162But if you need to have:
     164 * date+time data to be entered in different locations using the local time
     165 * such data be displayed in the local time at different locations different from the location where it was originally entered.
     167then more granularity is needed so different instances of date+time inside one application can be handled in a way that takes in account its timezone.
     169An additional possibility would to create an additional presentation layer, where an user location/timezone preference can influence and personalize the display of date+time's (see the Django template filter idea in one of the thread linked below.)
     171Other advantages of a solution to this problem could be: Isolation from daylight saving time political policy changes and isolation from changes on time zones should the hosting of a production application be moved form one geographical location to another.
     173Issues to consider:
     174 * Compatibility with all the DB backend officially supported by Django
     175 * Backwards compatibility: Existing installations shouldn't be affected at all regarding the storage/interpretation of `DateTime` model fields values
     177See also:
     178 * Tickets #2626, #10587 and possibly #1480 and #2447
     179 * A django-dev [ thread]
     180 * Another django-dev [ thread]
     181 * A [ blog post] describing how this was implemented for ''Ruby on Rails'' 2.1
     182 * [ timestamp] PostgreSQL data type documentation
     183 * Django `TIME_ZONE` setting documentation as of 1.2:
    156185=== Housekeeping ===
Back to Top