/srv/irclogs.ubuntu.com/2014/10/06/#ubuntu-autopilot.txt

=== vrruiz_ is now known as rvr
=== charles_ is now known as charles
nik90balloons: 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 :D18:49
nik90balloons: I forgot to bookmark it18:49
balloonsnik90, ahh, sure18:50
balloonshttp://www.tech-foo.net/on-test-levels-and-coverage.html18:51
nik90balloons: cool, thnx18:52
=== nik90 is now known as nik90|Dinner
* thomi blushes20:10
=== mihir_ is now known as mihir
=== nik90|Dinner is now known as nik90
veebersIs 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:34
veebersbarry: if you have some spare cycles, perhaps you have some insight?^21:57
thomiveebers: just got off the phone, sorry21:57
veebersno 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 over21:58
thomiveebers: if I had to guess, I'd say that 2 and 3 are in a TZ where DST has been applied, thus the differnt time21:59
thomiwhereas 1. doesn't have a TZ associated, so DST cannot be calculated21:59
thomithat's my guess21:59
veebersthomi: right, but they should be the same tz surely. Hmm ok, true, I just assumed it took localtime tz21:59
thomiveebers: no, it has no timezone22:07
thomiif you don't specify, you get a tz nieve object, which has no timezone, and so can't do DST calculations22:07
veebersthomi: then I might be screwed :-\22:08
thomiyou're never screwed, you just haven't found the right workaround yet22:09
thomiwhat's the issue?22:09
veebersI guess it was just coincidence that all the other testing I did (UTC, NZ, US/Central) in differentimes worked out22:09
thomihow's that?22:09
veebersthomi: the issue is that datetime.fromtimestamp(2983579200) != autopilot.types.DateTime(2983579200)22:10
veeberswhen the TZ is US/Pacific22:10
veebersthomi: I'll point you at the test I'm looking at22:10
thomiveebers: because the first is nieve, the second has a tz applied to it22:11
thomidoes the __eq__ op fail because one has a tz and the other doesn't, or because they represent different times?22:11
thomiI guess it must be the latter22:11
veebersthomi: 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 at22:17
balloonsoO22:19
veebersballoons: is that a reaction to my code? :-)22:19
veebersor the fact that we're still haven't solved this bug :-P22:20
balloonsveebers, no, just a comment on that fact there is code :-)22:20
balloonsI'm confident you've got it nailed now22:20
veebersballoons: 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:21
thomiveebers: 51-52 look suspicous to me22:22
* veebers looks22:22
veebersthomi: ah I think you are right. that looks like leftover code. gettz should cover that22:23
veebersaye it does, removing it now.22:23
thomialso, 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 though22:23
thomiin the mean time, make sure you've touched base with max22:23
thomiand you can also find some python help22:24
thomifrom #python, perhaps22:24
veebersthomi: ack, thanks22:26

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!