On Sep 8, 5:55 am, Kirit Sælensminde (kayess) <kirit.saelensmi...@gmail.com> wrote:
> There is also a Django time field. How to handle this is kind of hard > as having a timezone on a time field may not make much sense. At the > moment it is up to application code to combine this with a date in a > sane manner. If Django switches to use UTC internally then this is > going to become harder for many users to do correctly. Maybe some > library functions that will help them to do this will work? Whilst both the Python datetime.time type and the Postgres 'time with time zone' column type support a TZ, I personally feel that it only makes sense to attach TZ info for datetime.datetime (eg. 'timestamp with time zone'). Other people have raised the point before about the need to retain some way of expressing "wall clock time", and I *think* separate date and time fields address that issue reasonably well. Let's say we were to use TZ with simple datetime.time types. A user in America/Chicago (UTC-05) inputs a time of 18:00. This gets normalized to UTC and stored as 23:00. A user in Australia/Sydney (UTC+10) wishes to view that information, and sees the value localized for them as 09:00 - *the next day*. This is why I think it's best to leave TZ out of simple date or time types, and only use it on datetime types, that treat the concept of time as a constant, linear progression that is relative to the observer, not the event that takes place. The normalization to UTC is really only a factor for databases (or serializers) that don't already do their own internal storage as UTC. The application developer should be unaware that it was stored as UTC, since they are provided a non-naive datetime with tzinfo attached, which they can then localize to any other TZ they wish. > The other thing that ought to be thought about with this is the admin > time/date widgets which have the 'now' link. This is always filled in > with the browser's current time which plays havoc when admin is used > by a user in a different time zone to the site's settings. It should > be possible to capture the UTC offset along with the time so that the > correct number of minutes is added/subtracted when the field is > processed by Django. Thankfully daylight savings can be ignored here. If admins (or users) are inputting localized datetimes, the app will need to know their timezone, or apply a default system-wide timezone. I don't see this as much different from the way that the language cookie is used. Perhaps a formfield could allow for the specification of a UTC offset in the input, eg "2011-09-08 16:02+02" and extract that offset from the input. DST is irrelevant since UTC offset is not the same as timezone. A location's timezone is the same all year round, but the UTC offset changes at various times of the year if that timezone observes DST. That's part of the information provided by the Olson tzdata database. Usually when a timestamp shows a UTC offset, any DST offset is included in that UTC offset, so it can still be normalized to UTC regardless of DST being in effect or not. > Many browsers will send the local time of the request to the server. > This can be used to guess the correct timezone, but it won't get > things right (there's no way to work out the correct DST setting from > this). If the country can be identified in some way then the two > together should be good for most users. The UTC offset in the request > is all that's needed to get localize any times that are sent back > though as again, daylight savings can be ignored -- so long as we > aren't rash enough to presume that this offset tells us the actual > time zone. The JavaScript Date() object has several methods that could be useful here, including getTimezoneOffset(), which returns difference between UTC and local time, in minutes. Remember that Postgres is not storing the timezone. It's not even storing the UTC offset. The timezone is only a client connection "environment var", that gets added/subtracted to timestamps as they are input or retrieved. Likewise I don't think the objective here is to store a TZ with the DateTimeField, but rather just to have UTC offset information available during handling, that facilitates the normalization to/from UTC for non-TZ-capable databases. Whether that UTC offset information is in the form a full timezone name, such as America/Chicago, or simply a UTC offset such as UTC-05, is not particularly relevant. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
