[05:36] <LrdDimwit> I summon the dork powers that reside in this channel!
[05:37] <LrdDimwit> Anyone around?  I can't figure out which package this bug ought to be assigned to
[06:38] <LrdDimwit> apparently the answer is "no", no one is around
[17:12] <hggdh> LrdDimwit: well, depends... which bug?
[17:16] <LrdDimwit> Hggdh:  This bug
[17:16] <LrdDimwit> https://bugs.launchpad.net/ubuntu/+bug/1403301
[17:17] <LrdDimwit> all the instructions say "run the program then use the PID to [bunch of steps here]"
[17:17] <LrdDimwit> no instruction for what to do when that's not possible
[17:24] <teward> LrdDimwit: i don't see where you're getting that from, but the bug seems like it might exist in Trusty as well, assuming that the date string there is actually valid per the manpage
[17:24] <teward> (which it looks like it should be)
[17:24] <teward> hggdh: ^
[17:25] <teward> LrdDimwit: well note the bug is actually already assigned to coreutils
[17:25] <hggdh> looking
[17:26] <teward> (and that's what the bug SHOULD be against.)
[17:28] <LrdDimwit> ah, I didn't notice it had been updated since I reported it yesterday
[17:28] <teward> LrdDimwit: yep, things get overlooked from time to time - the bug is now against what it needs to be
[17:28] <LrdDimwit> (And I'm pretty sure it's a bug.  The format is valid for dates other than those listed, and I had a friend try on another distro (not sure whether was OSX or another flavor of Linux, didn't think to ask and I'm not at work right now) and he said it worked fine)
[17:28] <hggdh> WFM on coreutils 8.23 (Vivid)
[17:29] <teward> hggdh: i don't have a vivid VM around, have you tested Trusty or Utopic?  (I could probably test in a chroot but i'm lazy)
[17:29] <LrdDimwit> I have not
[17:29] <teward> LrdDimwit: i was talking to hggdh :)
[17:29] <hggdh> now out of curiosity, is March 9 2013 a day that changes daylight?
[17:29] <LrdDimwit> well I still haven't :)
[17:30] <LrdDimwit> I don't know
[17:30] <LrdDimwit> however if you look at the comment below that I added
[17:30] <LrdDimwit> that can't be the explanation
[17:30] <LrdDimwit> the missing date is always in either late march or April, but it moves around too much
[17:30] <hggdh> yes, it could, if this timestamp does not exist in that specific TZ/country
[17:31] <hggdh> but, of course, there is always the chance of being a bug...
[17:31] <teward> ooo good point, my TZ is America/New_York, lemme go throw this at my Etc/Utc VPSes
[17:31] <LrdDimwit> ah, I see
[17:32] <LrdDimwit> Aside from the fact a friend said the same command worked on another distro (leading me to believe no) I can look it up
[17:32] <LrdDimwit> "Daylight Saving Time (United States) 2014 began at 2:00 AM on
[17:32] <LrdDimwit> Sunday, March 9"
[17:33] <LrdDimwit> and it also began at 2 AM on March 10, 2013 (which is another date I listed as broken)
[17:34] <hggdh> LrdDimwit: what is your TZ?
[17:34] <LrdDimwit> California time
[17:34] <teward> hggdh: it's a TZ issue
[17:35] <teward> LrdDimwit: ^
[17:35] <teward> it works fine when timezone is Etc/Utc
[17:35] <teward> but when in a specific timezone with DST it doesn't appear to work - looks like it might be timezone related somewhat
[17:35] <teward> (this is why I say servers should all be Utc :P)
[17:36] <LrdDimwit> it definitely does sound related to daylight savings time.  I checked the switchover in 1984 and it turns out to be the day I listed in the bug
[17:36] <LrdDimwit> interestingly it doesn't seem to affect the days where there's an extra hour, just ones where it skips an hour (I know this cause I had a script creating a file for every day in the year going back 12K days into the past)
[17:37] <teward> hggdh: given it's a DST issue, any issue with me marking "Invalid" or "Incomplete"?
[17:37] <teward> (my description will detail what cases I tested to see that this isn't a bug)
[17:38] <hggdh> teward: go ahead, adding a comment that this is TZ/daylight savings-related
[17:39] <teward> done
[17:39] <hggdh> LrdDimwit: usually it is better to check/set times after a certain time (usually I set them all at 12:00) to bypass possible TZ issues
[17:39] <hggdh> teward: thank you sir, in your debt
[17:40] <teward> hggdh: or for servers, use all UTC and do the time conversion yourself
[17:40]  * teward is weird that way :P
[17:40] <LrdDimwit> this is my personal dev box.  Our servers ARE all in UTC (and I see now one very interesting reason why)
[17:40] <hggdh> teward: indeed. all my servers are UTC
[17:40] <LrdDimwit> So if I used 0300 or 0100 it would have worked?
[17:41] <hggdh> LrdDimwit: most probably. As long that this is a valid time in this date/TZ, it should work
[17:41] <LrdDimwit> if it does, then I agree it's not a bug.  Can't check right now (still getting ready to go to work) but I'll check when I get into the office
[17:42] <hggdh> LrdDimwit: yes, please do so, and comment on the bug (and reopen it if needed)
[17:42] <LrdDimwit> will do.
[17:42] <LrdDimwit> Thank you for your assistance
[17:43] <hggdh> you are welcome. Thank you for asking (and having the pacience to wait for a response)
[17:44] <LrdDimwit> eh, it's IRC.  IRC is asynchronous :)
[17:44] <hggdh> :-)
[17:44] <LrdDimwit> it's better than when I reported a bug in the Scala compiler and got one comment after filing, then nothing at all months later.  For a 100% repro compiler crash. :)
[17:44] <hggdh> heh
[17:45] <teward> Or, ask us to reopen
[17:45] <teward> hggdh: can normal users go from Invalid -> New ?
[17:45] <teward> I know I can because Bug Control, but can normal users
[17:45] <LrdDimwit> it might depend on whether said normal user is the originator?
[17:45] <hggdh> teward: yes, they should be able to
[17:45] <teward> ack
[17:47] <hggdh> BTW, it only worked for me because the machine I am running IRC from is under UTC...
[17:47] <teward> hggdh: right, i tested on my Precise and Trusty VMs (both UTC) so...
[17:47] <teward> meh