=== vrruiz_ is now known as rvr === charles_ is now known as charles [18:49] balloons: hey, sry you got that link to thomi's blog post about test coverage...I need to bookmark and do some quoting for my own blog post :D [18:49] balloons: I forgot to bookmark it [18:50] nik90, ahh, sure [18:51] http://www.tech-foo.net/on-test-levels-and-coverage.html [18:52] balloons: cool, thnx === nik90 is now known as nik90|Dinner [20:10] * thomi blushes === mihir_ is now known as mihir === nik90|Dinner is now known as nik90 [21:34] Is there anyone that can point me in the right direction with this date handling code? I want to know why method 1. is an hour different to methods 2 & 3: http://pastebin.ubuntu.com/8510318/ [21:57] barry: if you have some spare cycles, perhaps you have some insight?^ [21:57] veebers: just got off the phone, sorry [21:58] no worries thomi. I'm trying to get my head around why I'm seeing this hour difference. All the other issues I've come across i've been able to sort out, but this one isn't a push over [21:59] veebers: if I had to guess, I'd say that 2 and 3 are in a TZ where DST has been applied, thus the differnt time [21:59] whereas 1. doesn't have a TZ associated, so DST cannot be calculated [21:59] that's my guess [21:59] thomi: right, but they should be the same tz surely. Hmm ok, true, I just assumed it took localtime tz [22:07] veebers: no, it has no timezone [22:07] if you don't specify, you get a tz nieve object, which has no timezone, and so can't do DST calculations [22:08] thomi: then I might be screwed :-\ [22:09] you're never screwed, you just haven't found the right workaround yet [22:09] what's the issue? [22:09] I guess it was just coincidence that all the other testing I did (UTC, NZ, US/Central) in differentimes worked out [22:09] how's that? [22:10] thomi: the issue is that datetime.fromtimestamp(2983579200) != autopilot.types.DateTime(2983579200) [22:10] when the TZ is US/Pacific [22:10] thomi: I'll point you at the test I'm looking at [22:11] veebers: because the first is nieve, the second has a tz applied to it [22:11] does the __eq__ op fail because one has a tz and the other doesn't, or because they represent different times? [22:11] I guess it must be the latter [22:17] thomi: sorry was updating the code, MP is here: https://code.launchpad.net/~veebers/autopilot/fix-1328600-large-datetime/+merge/236815 lines 33-58 are the DateTime creation (handling large timestamps) line 303 is the test I'm currently looking at [22:19] oO [22:19] balloons: is that a reaction to my code? :-) [22:20] or the fact that we're still haven't solved this bug :-P [22:20] veebers, no, just a comment on that fact there is code :-) [22:20] I'm confident you've got it nailed now [22:21] balloons: heh, I'm not :-| which is why I'm trying to get it sorted out. (I _was_ confident late last night, but this little issue raised its head) [22:22] veebers: 51-52 look suspicous to me [22:22] * veebers looks [22:23] thomi: ah I think you are right. that looks like leftover code. gettz should cover that [22:23] aye it does, removing it now. [22:23] also, if you've hit a wall, you need to find some expert help. I don't have time this morning, I may have time this arvo though [22:23] in the mean time, make sure you've touched base with max [22:24] and you can also find some python help [22:24] from #python, perhaps [22:26] thomi: ack, thanks