On 25 kesä, 19:12, "Tom Tobin" <[EMAIL PROTECTED]> wrote:
> All PostgresSQL supports in terms of *storage* is > a fixedtimezoneoffset, not the actual zoneinfo name; this isn't > very useful, and causes problems such as the above. Actually, in PostgreSQL TIMESTAMP WITH TIME ZONE does NOT store the TIME ZONE! I found it out the hard way yesterday. BTW, what we would need at the moment in our project would be a DateTimeField with complete time zone support. It seems I have to both write the Field type completely from scratch, and it seems it has to be multi-column on MySQL (must store time in UTC, along with separate textual time zone). Anyway, I believe that that approach together with time zone aware datetime objects would get rid of lot of ambiguity and problems for good. To someone thinking about the problems involved with storing times in local time: The reason why this is bad is the DST changes: on the last Sunday of October in EU there's an extra hour added, with for example times 3:00-3:59 occuring twice in EE(S)T zone. If you don't store the time zone, hours 1:00-3:00 UTC will be ambiguous. Also, were you storing local times in database, you could pretty easily ruin the database if you decided to change the time zone in the model... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
