Re: Multiple timezone support for datetime representation
On Sep 8, 5:55 am, Kirit Sælensminde (kayess) 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.
Re: PHP-inspired user-friendly in-browser DJango install
On Wed, 2011-09-07 at 19:08 +0100, Cal Leeming [Simplicity Media Ltd] wrote: > Uh.. what? Django != Drupal. > > Can you please explain a bit more about what you want the end result > to be. I do not think you have fully read the post - he wants users to be able to set up their django sites with a GUI. -- regards Kenneth Gonsalves -- 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.
Re: ticket 13125 is waiting for a design decision for 18 months
Could anyone provide a use case where I want a de-activated user to remain authenticated? Who is this option for? Why is it default? When I originally reported this ticket I did so because this is a plain security risk--non-technical users uncheck 'is active' when they want to lock someone out of access. They don't realize that the session remains active and I believe this to be an oversight within the original design, not a design preference. On Sep 8, 2:11 am, Vladimir Kryachko wrote: > I think it has been done on purpose, and should not be changed. > Because different authentication backends may choose to support > inactive users or not. And the default (ModelBackend) supports > inactive users which is expressed in > ModelBackend.supports_inactive_user = True. So I would suggest you > write a custom decorator. > > > > > > > > On Fri, Sep 2, 2011 at 6:49 AM, Wim Feijen wrote: > > I'd like to draw attention to an open ticket which needs a design > > decision. > > > Description: > > "The login_required decorator is not checking User.is_active, as > > staff_member_required does. If an authenticated user is deactivated > > (via setting is_active to False), the user is still able to browse > > login_required-protected views." > > > For probably most people, the expected and (most likely) wanted > > behavior would be not to let inactive users have access to > > login_required files. > > > Wim > > > -- > > 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 > > athttp://groups.google.com/group/django-developers?hl=en. -- 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.
Re: PHP-inspired user-friendly in-browser DJango install
Hi Alec, Nothing prevents you from altering the settings file dynamically and telling the user to restart the webserver. You can run wih an in-memory SQLite database until this is done. So your question isn't related to the development of Django itself; it would be more appropriate on django-users. Note that deploying a Django project is a bit more complicated than a PHP project (just throw the files in WWW_ROOT). IMO setting up the database isn't the most difficult step. I don't know any projects that provide this feature. Best regards, -- Aymeric. Le 6 sept. 2011 à 19:29, Alec Taylor a écrit : > Good morning, > > I have been using Drupal for a while now, but am slowly moving toward > DJango. > > I am currently working on quite an ambitious project, which I will be > releasing under a permissive license (New BSD or better). > > I would like my project to be as accessible as possible. To this end, > I would like people without any Python or DJango knowledge to be able > to quickly setup my project. > > Here is the web-interface functionality I would like to present to the > user: > > > > > > > > > > [Install] > > Can DJango be made do work this way? — If so, do you have some example > code or an existing project which does this? > > Thanks for all suggestions, > > Alec Taylor > > -- > 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. > -- 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.
