Re: how to deploy an app that gets used by people in multiple time zones

[Margie]

Sorry for the delay in response - was on vacation for a few days.

After reading up more on naive and aware timezones in python, this all
makes more sense now.  Thanks for your pointers, they were helpful.

Margie

On Sep 4, 9:03 am, Brian Neal  wrote:
> On Sep 4, 10:47 am, Margie  wrote:
>
>
>
> > Can someone clarify what format dates and times are stored in when
> > using just a standard DateTimeField?  Is mytimezoneencoded in the
> > database or is some generic, non-timezone-specific date/time stored?
>
> There is notimezoneencoded. The dates/times are said to be "naive".
>
> It is up to you to assign meaning to the time and to convert to the
> appropriatetimezonefor your users.
>
> You should probably review this:
>
> http://docs.python.org/library/datetime.html
>
> Regards,
> BN
>
> PS. The pytz library is useful for performing conversions between
> timezones.http://pytz.sourceforge.net/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: how to deploy an app that gets used by people in multiple time zones

[Margie]

Tracy,

Sorry for the delay, just got back from a short vacation.  Thanks very
much for your clarification.  I think I now understand how to proceed!

On Sep 7, 8:06 pm, Tracy Reed  wrote:
> On Thu, Sep 03, 2009 at 03:48:14PM -0700, Margie spake thusly:
>
> > What is the default when using a django DateTimeField? Does it not
> > save it in UTC? If it is not saving it in UTC, what is it saving it
> > in?
>
> Python has two kinds of DateTime objects: naive and
> non-naive. Non-naive has timezone information with it. But the Django
> DateTimeField can only handle naive DateTime objects since MySQL
> cannot store time zones. So anytime you assign a time to a
> DateTimeField you have to convert it to a standard timezone and UTC is
> the most logical choice.
>
> > I thought that one of the things the DateTimeField did for you
> > was convert your input (whether form a user typed input or from a
> > server call to datetime.datetime.now ()) into some sort of internal
> > representation (UTC?).
>
> I think it would be nice if it did this automatically since that is
> the only thing that makes sense but it does not. Maybe someone out
> there is able to be 100% sure that their data will always be the same
> timezone so they don't want to inconvenience them by forcing
> everything to UTC so they have to do a conversion to localtime when
> they get their data back out. But I think such cases are exceedingly
> rare. So we are all stuck converting to UTC before doing a .save() on
> our models.
>
> > I thought that when I was using the date filter, that it was simply
> > converting that internal representation into my specificied text
> > format.  Am I confused here?
>
> It does that but it does not do any timezone conversions.
>
> > I thought about putting the timezone in the profile but that does have
> > the disadvantage that if the user travels, they would have to update
> > their profile to get dates displayed in whatever location they are
> > at.  I really don't like that since the people that will be using my
> > app are management, and they often travel (and probably won't want to
> > modify their profile all the time).
>
> There is no way around this afaik. They need to learn to do timezone
> conversions in their head or set a timezone in their profile. I label
> the timezone displayed prominently so they know to make the adjustment
> or change their profile.
>
> --
> Tracy Reedhttp://tracyreed.org
>
>  application_pgp-signature_part
> < 1KViewDownload
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: how to deploy an app that gets used by people in multiple time zones

[Tracy Reed]

On Thu, Sep 03, 2009 at 03:48:14PM -0700, Margie spake thusly:
> What is the default when using a django DateTimeField? Does it not
> save it in UTC? If it is not saving it in UTC, what is it saving it
> in?

Python has two kinds of DateTime objects: naive and
non-naive. Non-naive has timezone information with it. But the Django
DateTimeField can only handle naive DateTime objects since MySQL
cannot store time zones. So anytime you assign a time to a
DateTimeField you have to convert it to a standard timezone and UTC is
the most logical choice.

> I thought that one of the things the DateTimeField did for you
> was convert your input (whether form a user typed input or from a
> server call to datetime.datetime.now ()) into some sort of internal
> representation (UTC?).

I think it would be nice if it did this automatically since that is
the only thing that makes sense but it does not. Maybe someone out
there is able to be 100% sure that their data will always be the same
timezone so they don't want to inconvenience them by forcing
everything to UTC so they have to do a conversion to localtime when
they get their data back out. But I think such cases are exceedingly
rare. So we are all stuck converting to UTC before doing a .save() on
our models.

> I thought that when I was using the date filter, that it was simply
> converting that internal representation into my specificied text
> format.  Am I confused here?

It does that but it does not do any timezone conversions.

> I thought about putting the timezone in the profile but that does have
> the disadvantage that if the user travels, they would have to update
> their profile to get dates displayed in whatever location they are
> at.  I really don't like that since the people that will be using my
> app are management, and they often travel (and probably won't want to
> modify their profile all the time).

There is no way around this afaik. They need to learn to do timezone
conversions in their head or set a timezone in their profile. I label
the timezone displayed prominently so they know to make the adjustment
or change their profile.

-- 
Tracy Reed
http://tracyreed.org


pgpEwkmUhbJCF.pgp
Description: PGP signature

Re: how to deploy an app that gets used by people in multiple time zones

[Brian Neal]

On Sep 4, 10:47 am, Margie  wrote:
>
> Can someone clarify what format dates and times are stored in when
> using just a standard DateTimeField?  Is my timezone encoded in the
> database or is some generic, non-timezone-specific date/time stored?

There is no timezone encoded. The dates/times are said to be "naive".

It is up to you to assign meaning to the time and to convert to the
appropriate timezone for your users.

You should probably review this:

http://docs.python.org/library/datetime.html

Regards,
BN

PS. The pytz library is useful for performing conversions between
timezones.
http://pytz.sourceforge.net/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: how to deploy an app that gets used by people in multiple time zones

[Margie]

I am using mysql.

Can someone clarify what format dates and times are stored in when
using just a standard DateTimeField?  Is my timezone encoded in the
database or is some generic, non-timezone-specific date/time stored?

I don't understand why I would want to save my timezone along with my
date/time.  It seems to me that I should just be saving the generic
form of the date/time and then rendering it in the format approriate
for the user that it is being rendered for.  IE, use the timezone only
when rendering, not when saving.

Margie


On Sep 4, 12:22 am, Maksymus007  wrote:
> On Thu, Sep 3, 2009 at 11:36 PM, Margie
>
>
>
> Roginski wrote:
>
> > I've created a django app and I soon am going to have users that are
> > in multiple timezones.  My app is a task management system and it is
> > important for users to see dates and times with respect to their own
> > time zone.  IE, if here in California I create a task at 3PM on Sept
> > 3, I want someone in India to see it as being created at 1AM on Sept
> > 4.  Optimally, if that India employee travels to the US and looks at
> > the task creation date, they should see 3PM on Sept 3.   Is there a
> > "best" way to handle this?  Things that come to mind are:
>
> >  1. Create a deployment for each of my time zones where TIME_ZONE and
> > DATE_FORMAT are set appropriately for the time zone associated with
> > the deployment.  This seems painful ...
>
> >  2. Have a single deployment and whenever I display dates, use some
> > sort of tag that can figure out how to display the date correctly
> > based on the user's time zone
>
> >  3. I see there is a reusable app called django-timezones.  There is
> > not much doc with it, but I'm guessing this is targeted at what I am
> > trying to do.
>
> > Can anyone give any recommendations?  I'm happy to dive in and read
> > source (ie, for django-timezones app), but I just want to make sure
> > I'm heading in the right direction.
>
> > Thanks,
>
> have you tried to use postgres timestamp with time zone field? It has
> ability to make such a conversion on the fly and every date can be
> stored with timezone
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: how to deploy an app that gets used by people in multiple time zones

[Maksymus007]

On Thu, Sep 3, 2009 at 11:36 PM, Margie
Roginski wrote:
>
> I've created a django app and I soon am going to have users that are
> in multiple timezones.  My app is a task management system and it is
> important for users to see dates and times with respect to their own
> time zone.  IE, if here in California I create a task at 3PM on Sept
> 3, I want someone in India to see it as being created at 1AM on Sept
> 4.  Optimally, if that India employee travels to the US and looks at
> the task creation date, they should see 3PM on Sept 3.   Is there a
> "best" way to handle this?  Things that come to mind are:
>
>  1. Create a deployment for each of my time zones where TIME_ZONE and
> DATE_FORMAT are set appropriately for the time zone associated with
> the deployment.  This seems painful ...
>
>  2. Have a single deployment and whenever I display dates, use some
> sort of tag that can figure out how to display the date correctly
> based on the user's time zone
>
>  3. I see there is a reusable app called django-timezones.  There is
> not much doc with it, but I'm guessing this is targeted at what I am
> trying to do.
>
> Can anyone give any recommendations?  I'm happy to dive in and read
> source (ie, for django-timezones app), but I just want to make sure
> I'm heading in the right direction.
>
> Thanks,

have you tried to use postgres timestamp with time zone field? It has
ability to make such a conversion on the fly and every date can be
stored with timezone

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: how to deploy an app that gets used by people in multiple time zones

[Margie]

Thanks for the input.  I have a couple questions.  Both of you talk
about saving the date/time in UTC format.  What is the default when
using a django DateTimeField? Does it not save it in UTC? If it is not
saving it in UTC, what is it saving it in?  I thought that one of the
things the DateTimeField did for you was convert your input (whether
form a user typed input or from a server call to datetime.datetime.now
()) into some sort of internal representation (UTC?).  I thought that
when I was using the date filter, that it was simply converting that
internal representation into my specificied text format.  Am I
confused here?

I thought about putting the timezone in the profile but that does have
the disadvantage that if the user travels, they would have to update
their profile to get dates displayed in whatever location they are
at.  I really don't like that since the people that will be using my
app are management, and they often travel (and probably won't want to
modify their profile all the time).

One thing I thought about is trying to save the timezone info in the
session.  It seems like there should be a way to set a session
variable at login time that reflects the current time zone and then
have template tags that access that variable and generate the correct
format based on the session variable.Is this a viable option?

Since this is an internal site within a company, it is ok for me to
require my users to have javascript on.  Tim - i assume that with
respect to your comment about javascript you are suggesting that
identify the timezone via client javascript code and send it with
every request?

I thought I had read there was something going on in this area,
possibly for django 1.2 but I can't remember what I saw about
that ...  Would be curious if there is anything planned for develpment
in this area as I could possibly wait a few months to implement this
if there was going to be some additional support coming on the django
side.

Margie


On Sep 3, 3:02 pm, Tim Chase  wrote:
> > I've created a django app and I soon am going to have users that are
> > in multiple timezones.  My app is a task management system and it is
> > important for users to see dates and times with respect to their own
> > time zone.  IE, if here in California I create a task at 3PM on Sept
> > 3, I want someone in India to see it as being created at 1AM on Sept
> > 4.  Optimally, if that India employee travels to the US and looks at
> > the task creation date, they should see 3PM on Sept 3.   Is there a
> > "best" way to handle this?  Things that come to mind are:
>
> >  1. Create a deployment for each of my time zones where TIME_ZONE and
> > DATE_FORMAT are set appropriately for the time zone associated with
> > the deployment.  This seems painful ...
>
> agreed...yuck!
>
> >  2. Have a single deployment and whenever I display dates, use some
> > sort of tag that can figure out how to display the date correctly
> > based on the user's time zone
>
> Best that I've found.  It's best to store everything in the
> database as UTC and then adjust the display for whatever the
> relative timezone is.
>
> >  3. I see there is a reusable app called django-timezones.  There is
> > not much doc with it, but I'm guessing this is targeted at what I am
> > trying to do.
>
> Not familiar with this one.
>
> The catch is that HTTP doesn't require the requester to send
> their timezone information in the request.  So you either have to
> store the user's TZ in their user profile information, or you
> have to use some client-side JavaScript to get the local TZ.
> Both have problems -- If the client has JavaScript turned off (I
> tend to fly with NoScript, only white-listing those sites I care
> about to be able to run JS) you don't get this information back
> from them.  On the other side, if your customers travel from TZ
> to TZ, they will have to update their profile each time they
> move.  Neither is a horrible solution, just with their own set of
> hiccups.  The two solutions can be combined to keep an "expected
> TZ" in the user profile, but then take advantage of JS when
> available to sniff the local PC's time-zone to override.
>
> Python's stock TZ handling is a little weak last I experimented
> with it, expecting a single TZ for the entire running instance.
> There's a library at pytz.sf.net that simplifies a lot of the TZ
> pain I've experienced with Python's native datetime libraries.
> It also gives good examples and cautions on things that can screw
> you up (such as notifications set during a DST rollback time-slot).
>
> Hope this helps,
>
> -tim
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 

Re: how to deploy an app that gets used by people in multiple time zones

[Tim Chase]

> I've created a django app and I soon am going to have users that are
> in multiple timezones.  My app is a task management system and it is
> important for users to see dates and times with respect to their own
> time zone.  IE, if here in California I create a task at 3PM on Sept
> 3, I want someone in India to see it as being created at 1AM on Sept
> 4.  Optimally, if that India employee travels to the US and looks at
> the task creation date, they should see 3PM on Sept 3.   Is there a
> "best" way to handle this?  Things that come to mind are:
> 
>  1. Create a deployment for each of my time zones where TIME_ZONE and
> DATE_FORMAT are set appropriately for the time zone associated with
> the deployment.  This seems painful ...

agreed...yuck!

>  2. Have a single deployment and whenever I display dates, use some
> sort of tag that can figure out how to display the date correctly
> based on the user's time zone

Best that I've found.  It's best to store everything in the 
database as UTC and then adjust the display for whatever the 
relative timezone is.

>  3. I see there is a reusable app called django-timezones.  There is
> not much doc with it, but I'm guessing this is targeted at what I am
> trying to do.

Not familiar with this one.

The catch is that HTTP doesn't require the requester to send 
their timezone information in the request.  So you either have to 
store the user's TZ in their user profile information, or you 
have to use some client-side JavaScript to get the local TZ. 
Both have problems -- If the client has JavaScript turned off (I 
tend to fly with NoScript, only white-listing those sites I care 
about to be able to run JS) you don't get this information back 
from them.  On the other side, if your customers travel from TZ 
to TZ, they will have to update their profile each time they 
move.  Neither is a horrible solution, just with their own set of 
hiccups.  The two solutions can be combined to keep an "expected 
TZ" in the user profile, but then take advantage of JS when 
available to sniff the local PC's time-zone to override.

Python's stock TZ handling is a little weak last I experimented 
with it, expecting a single TZ for the entire running instance. 
There's a library at pytz.sf.net that simplifies a lot of the TZ 
pain I've experienced with Python's native datetime libraries. 
It also gives good examples and cautions on things that can screw 
you up (such as notifications set during a DST rollback time-slot).

Hope this helps,

-tim










--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: how to deploy an app that gets used by people in multiple time zones

[Tracy Reed]

On Thu, Sep 03, 2009 at 02:36:21PM -0700, Margie Roginski spake thusly:
> the task creation date, they should see 3PM on Sept 3.   Is there a
> "best" way to handle this?  Things that come to mind are:

I am going to have to be dealing with this soon also. My plan is to
store datetime objects in the db in UTC. I then plan to have a user
profile with a timezone attribute for that user. Whenever I display a
date/time to the user I intend to convert it to their timezone. 

I am wondering if I have to just make an explicit conversion
everywhere I end up displaying them a time or if there is some slick
way I can override a method on datetime objects to automatically have
them return the correct timezone when being rendered in a template and
always be in UTC when going into the database.

-- 
Tracy Reed


pgpNsO1wxrEbn.pgp
Description: PGP signature

how to deploy an app that gets used by people in multiple time zones

[Margie Roginski]

I've created a django app and I soon am going to have users that are
in multiple timezones.  My app is a task management system and it is
important for users to see dates and times with respect to their own
time zone.  IE, if here in California I create a task at 3PM on Sept
3, I want someone in India to see it as being created at 1AM on Sept
4.  Optimally, if that India employee travels to the US and looks at
the task creation date, they should see 3PM on Sept 3.   Is there a
"best" way to handle this?  Things that come to mind are:

 1. Create a deployment for each of my time zones where TIME_ZONE and
DATE_FORMAT are set appropriately for the time zone associated with
the deployment.  This seems painful ...

 2. Have a single deployment and whenever I display dates, use some
sort of tag that can figure out how to display the date correctly
based on the user's time zone

 3. I see there is a reusable app called django-timezones.  There is
not much doc with it, but I'm guessing this is targeted at what I am
trying to do.

Can anyone give any recommendations?  I'm happy to dive in and read
source (ie, for django-timezones app), but I just want to make sure
I'm heading in the right direction.

Thanks,

Margie
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---