| 02:54.31 | *** join/#storm infobot (~infobot@rikers.org) |
| 02:54.32 | *** topic/#storm is The Storm Python ORM - http://storm.canonical.com/ - 0.19 released! || Review branches: https://code.launchpad.net/storm/+activereviews || IRC logs: http://ibot.rikers.org/#storm/ || API documentation: http://people.canonical.com/~jkakar/storm/ |
| 05:28.13 | *** join/#storm bigdog (~scmikes@8.8.197.72) |
| 07:40.03 | *** join/#storm bigkevmcd (~kevin@87-194-156-112.bethere.co.uk) |
| 07:45.54 | *** join/#storm munderwo (~markl@203-206-133-216.perm.iinet.net.au) |
| 07:46.54 | munderwo | Hi all. Is there a way to set the connections timezone in storm so when selecting a timestamp with timezone column it comes back correctly? |
| 07:47.19 | munderwo | or more accuratly with that timezone set |
| 08:05.05 | jamesh | I'd suggest doing your timezone handling on the client side. Storm makes this pretty easy to do with the DateTime property's tzinfo property |
| 08:05.35 | jamesh | set it to a UTC tzinfo object, and define your columns as "timestamp without time zone" |
| 08:15.45 | *** join/#storm zmijunkie (~sascha@pd95b6fd9.dip0.t-ipconnect.de) |
| 08:25.31 | munderwo | jamesh: hrmm.. see the thing is the Postgres guys seem to think that you should always use timestamp WITH time zone" whats the reason for using timestamp without time zone in your opinion? |
| 08:26.54 | *** join/#storm m4v (~znc@unaffiliated/m4v) |
| 08:27.20 | jamesh | munderwo: I guess my view is coloured by working with web applications with global audiences. |
| 08:27.45 | jamesh | munderwo: a "timestamp with time zone" column doesn't actually store any more information than a "timestamp without time zone" column |
| 08:28.16 | munderwo | jamesh: from whatI understand, a global audience means you would want to use it.. |
| 08:28.16 | jamesh | the only difference is that the "with time zone" variant performs a conversion on reads and writes depending on the connection's time zone setting |
| 08:29.45 | jamesh | that granularity isn't fine enough for the cases I've needed to work with time zones: we have many users from different time zones whose work will be funnelled through a much smaller set of connections to the database |
| 08:30.29 | munderwo | jamesh: right.. so because you are connection pooling, setting the connection timezone is not going to work.. |
| 08:30.42 | jamesh | so you either (a) continually change the connection's time zone depending on which user you're performing work on behalf of, or (b) use a fixed time zone for the connection and perform your own time zone conversions |
| 08:30.59 | jamesh | I used (b) with UTC as the fixed time zone |
| 08:31.25 | munderwo | right, did you use pytz in the calculations? |
| 08:31.29 | munderwo | in (b) |
| 08:31.58 | jamesh | I also needed to do some time zone aware calculations within the application code anyway, so I needed time zone awareness on the application side (and in particular, a way to determine what time zone the values from the database were in) |
| 08:32.14 | jamesh | yes, I did use pytz |
| 08:32.41 | munderwo | right, did you have the timezone ie ('Australia/Perth') or the offset ('+8') |
| 08:34.24 | jamesh | we used full time zone names, since we don't just deal with present time offsets |
| 08:34.54 | jamesh | (the big web app is https://launchpad.net -- you can configure the time zone in your user preferences) |
| 08:35.12 | munderwo | jamesh: oh THAT big web app :) |
| 08:35.48 | munderwo | right, we were looking at discovering it on the fly from javascript (I know there are a few problems with this approach, and if we need settable timezones we can do that) |
| 08:37.08 | munderwo | and the easiest way to do that is to get the offset.. |
| 08:37.28 | jamesh | right. That was one of the approaches we looked at way back, but it doesn't tell you anything about past or future dates |
| 08:37.30 | munderwo | but I guess the problem with that is your not really setting a timezone then.. |
| 08:37.57 | munderwo | hmm... Im trying to work out if we care about past or future dates.. |
| 08:38.11 | jamesh | it might tell you that you're in UTC+8, but that doesn't tell you whether the user's time zone has daylight savings, and whether it is north or southern hemisphere daylight saving |
| 08:38.30 | jamesh | or whether it is Perth where you had daylight saving a few years back but don't any more |
| 08:39.16 | munderwo | jamesh: Oh Perth and Daylight savings... dont get anybody in WA started on daylight savings... |
| 08:39.29 | jamesh | is in WA |
| 08:39.51 | munderwo | jamesh: reallY/ wow! you work for mozilla? |
| 08:40.02 | munderwo | <PROTECTED> |
| 08:40.05 | jamesh | munderwo: nope. Canonical |
| 08:40.26 | munderwo | Right yes, all these OSS companies... you work remote? |
| 08:40.34 | jamesh | yeah |
| 08:41.24 | munderwo | thats cool! I knew we had some guys in Australia (I saw a guy do a PyCon talk from last year) but I didnt think Perth!... its amazing the peeps perth has! |
| 08:43.37 | jamesh | I don't work on Launchpad these days, but the way I originally set things up for time zones was to keep times in UTC for most of the code paths. |
| 08:44.14 | jamesh | A template tag would take a datetime object and convert it to the user's time zone (or UTC for anonymous users) just before displaying it |
| 08:44.40 | jamesh | and similarly, the form processing code could attach the user's time zone to form data |
| 08:44.46 | munderwo | Anyway, I guess we need to workout how accurate our historical timestamps need to be... hmm.. and maybe we shouldnt be using timestamps with timezone... I think the thing that might trip us up in the future is shared connections... |
| 08:45.23 | munderwo | yeah I think we were going to put the offset (because it was the easiest thing to get from javascript) in a session object and just use that to do the timezone stuff. |
| 08:45.54 | jamesh | there were a few special cases, like the sprint/meeting management part of the app, where it made sense to work with times in the sprint's time zone |
| 08:45.57 | munderwo | but the conversion from offset to timezone is the tricky one.. |
| 08:46.44 | munderwo | jamesh: hrrmm.. lots to think about.. what do you work on now if you dont mind me asking? |
| 08:47.41 | jamesh | yep. If you want to have proper time zone handling, you probably need to get the user to tell you where they are. You might be able to use the detected current time zone offset to suggest some probable time zones though. |
| 08:47.52 | jamesh | I work on Ubuntu One these days |
| 08:48.57 | munderwo | jamesh: oh that must be fun... although I dont envy the remote working... I worked from home for the first six months of this year... you can only have so much conversation with your dogs before you go a little bit crazy ;) |
| 08:49.52 | munderwo | jamesh: luckily atm we are australia/nz only, so we would get pretty accurate in most cases. it would just be daylight savings that we would need to worry about.. |
| 08:50.40 | jamesh | I guess as long as people sign up for your service in the summer, you should have a pretty good idea of their time zone |
| 08:53.11 | jamesh | in the winter, you won't easily be able to differentiate between NT vs. SA or Qld vs. NSW,Vic,ACT,Tas |
| 08:54.17 | munderwo | yeah.. I Think its more a problem with historical data rather than anything else? ie what was this datetime last year in melbourne? |
| 09:04.52 | munderwo | jamesh: right I think we have it. We actually already have a location of sorts for the user. So we can just infer the timezone from there, and the convert to UTC and put in the db. Then when getting it out we just use the users timezone to convert back to localized time and we win! |
| 09:33.17 | *** join/#storm esteve (~quassel@cli-5b7ee9bd.bcn.adamo.es) |
| 10:32.45 | *** join/#storm esteve (~quassel@cli-5b7ee9bd.bcn.adamo.es) |
| 11:01.23 | *** join/#storm esteve (~quassel@cli-5b7ef037.bcn.adamo.es) |
| 11:12.25 | *** join/#storm artista_frustrad (~artista_f@187.55.101.27) |
| 11:28.18 | *** join/#storm esteve_ (~quassel@cli-5b7ee9bd.bcn.adamo.es) |
| 11:32.32 | *** join/#storm artista_frustrad (~artista_f@187.55.101.27) |
| 12:02.01 | *** join/#storm artista_frustrad (~artista_f@187.55.101.27) |
| 12:11.54 | *** join/#storm m4v (~znc@unaffiliated/m4v) |
| 12:45.46 | *** join/#storm artista_frustrad (~artista_f@187.55.101.27) |
| 13:18.39 | *** join/#storm artista_frustrad (~artista_f@187.55.101.27) |
| 14:08.56 | *** join/#storm _mup_ (~mup@li37-90.members.linode.com) |
| 16:02.42 | *** join/#storm artista_frustrad (~artista_f@187.55.100.62) |
| 16:47.29 | *** join/#storm artista_frustrad (~artista_f@187.55.100.62) |
| 17:31.11 | *** join/#storm artista_frustrad (~artista_f@187.55.100.62) |
| 18:02.35 | *** join/#storm artista_frustrad (~artista_f@187.6.155.105) |
| 18:25.21 | *** join/#storm artista_frustrad (~artista_f@187.6.155.105) |
| 19:01.16 | *** join/#storm lifeless (~robertc@122.58.129.196) |
| 19:39.02 | *** join/#storm jkakar (~jkakar@S0106602ad06e3f4b.vc.shawcable.net) |
| 19:45.16 | *** part/#storm jkakar (~jkakar@S0106602ad06e3f4b.vc.shawcable.net) |
| 22:11.17 | *** join/#storm lifeless (~robertc@122.58.129.196) |
| 22:45.42 | *** join/#storm bigdog1 (~scmikes@8.8.197.72) |
| 23:52.01 | *** join/#storm munderwo (~markl@203-206-133-216.perm.iinet.net.au) |