[15:39] <powersj> hehe "AssertionError: 'HST' not found in 'HDT\n'" silly daylight savings messing with my integration tests
[15:43] <rharper> lol
[17:13] <smoser> powersj, i put  a comment on your mp... i may be over thinking things.
[17:28] <powersj> smoser: hmm but won't that change between -0900 and -0800 depending on day light savings?
[17:28] <smoser> it should not.
[17:29] <powersj> and that command depends on what timezone you are in
[17:29] <powersj> which is ok, since we are setting
[17:29] <smoser> no... we specify the full time with offset -0400
[17:29] <powersj> yes, but the output changes... here is mine: "Wed, 02 Nov 2016 22:47:00 -0600"
[17:29] <smoser>  Thu, 03 Nov 2016 00:47:00 -0400 == Wed, 02 Nov 2016 19:47:00 -0900
[17:30] <powersj> oh... maybe that's what I'm not getting
[17:30] <smoser> the output changes based on the default time zone of the system.
[17:30] <smoser> (your default time zone is 0600)
[17:30] <smoser> but the test is testing that we can set the default time zone to US/wierd-timezone
[17:30] <smoser> that must be hawaii ?
[17:30] <powersj> it is Hawaii
[17:32] <smoser> so .. if we correctly set the timezone
[17:32] <smoser> date will always convert the '--date' to the default timezone of the system.
[17:32] <smoser> and so we're checking that dates output was converted to the time zone that we expect to have set the system to
[17:32] <smoser> right?
[17:33] <powersj> yeah, let me change it and play with it a bit. Never used date like that before, so still grawking it.
[17:33] <smoser> :)
[17:33] <rharper> alternatively can't we check that /etc/localtime points to the right tz we specified?
[17:36] <powersj> ah that might be good too, check that symlink
[17:37] <smoser> http://paste.ubuntu.com/24171815/
[17:37] <smoser> maybe that helps ?
[17:39] <smoser> well, the symlink could work, but that is somewhat of an implementation detail.
[17:39] <powersj> smoser: it does, thanks :)
[17:39] <smoser> where as the other way depends on 'date' behaviing correclty.
[18:35] <smoser> powersj, did you open a bug ?
[18:35] <smoser> for the timezone?
[18:35] <powersj> smoser: no
[18:35] <smoser> k
[18:35] <powersj> I did wrt the new password change (a 2nd one)
[18:36] <powersj> I'll get the timezone merge fixed up here in a bit
[18:38] <smoser> http://paste.ubuntu.com/24172068/
[18:39] <powersj> lol
[18:39] <powersj> thank you :)
[18:39] <smoser> i'll just take that now. i think the comnments there make it more clear than my explanation before.
[18:40] <powersj> smoser: yes they do and wfm thanks
[18:40] <smoser> early november is probably a really bad time to pick
[18:40] <powersj> why?
[18:40] <smoser> as someone might think that is on the cusp of a time change.
[18:41] <powersj> ah
[18:41] <smoser> but i'm using it anyway
[18:41] <smoser> :)
[20:31] <smoser> powersj, you mentioned something about cloud-init tags and buildilng ?
[20:31] <smoser> in your qa report
[20:31] <smoser> more info ?
[20:31] <powersj> I was trying to understand why we needed the tags when setup.py runs. I had not looked at that file enough to understand how it gets packaged up
[20:32] <powersj> So looked into how you specify an init system and the check that occurs when building cloud-init via tag + version in __init__
[20:32] <smoser> yeah, the check can be annoying for sure, but you should always have some tag to base it off of.
[20:33] <powersj> I've been played with snap'ing cloud-init as well and the python plugin doesn't take an option so I couldn't specify an init system
[20:33] <powersj> Even if it doesn't quite make sense too, it was an interesting lesson :)
[20:36] <smoser> powersj, python plugin doesnt take an option
[20:36] <smoser> ?
[20:37] <smoser> you mean tryin to get the init system into setup.py ?
[20:37] <powersj> yes
[20:38] <powersj> so your part would look like this: https://paste.ubuntu.com/24172666/
[20:38] <powersj> and we would want a "options: ['--systemd']" or something like that
[20:40] <powersj> This all started because I was looking at https://build.snapcraft.io/