/srv/irclogs.ubuntu.com/2014/12/17/#ubuntu-bugs.txt

=== Nigel_ is now known as G
LrdDimwitI summon the dork powers that reside in this channel!05:36
LrdDimwitAnyone around?  I can't figure out which package this bug ought to be assigned to05:37
LrdDimwitapparently the answer is "no", no one is around06:38
hggdhLrdDimwit: well, depends... which bug?17:12
LrdDimwitHggdh:  This bug17:16
LrdDimwithttps://bugs.launchpad.net/ubuntu/+bug/140330117:16
ubot5Launchpad bug 1403301 in coreutils (Ubuntu) "Ubuntu 12.04 touch -t does not work for March 9 2014" [Undecided,New]17:16
LrdDimwitall the instructions say "run the program then use the PID to [bunch of steps here]"17:17
LrdDimwitno instruction for what to do when that's not possible17:17
tewardLrdDimwit: 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 manpage17:24
teward(which it looks like it should be)17:24
tewardhggdh: ^17:24
tewardLrdDimwit: well note the bug is actually already assigned to coreutils17:25
hggdhlooking17:25
teward(and that's what the bug SHOULD be against.)17:26
LrdDimwitah, I didn't notice it had been updated since I reported it yesterday17:28
tewardLrdDimwit: yep, things get overlooked from time to time - the bug is now against what it needs to be17: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
hggdhWFM on coreutils 8.23 (Vivid)17:28
tewardhggdh: 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
LrdDimwitI have not17:29
tewardLrdDimwit: i was talking to hggdh :)17:29
hggdhnow out of curiosity, is March 9 2013 a day that changes daylight?17:29
LrdDimwitwell I still haven't :)17:29
LrdDimwitI don't know17:30
LrdDimwithowever if you look at the comment below that I added17:30
LrdDimwitthat can't be the explanation17:30
LrdDimwitthe missing date is always in either late march or April, but it moves around too much17:30
hggdhyes, it could, if this timestamp does not exist in that specific TZ/country17:30
hggdhbut, of course, there is always the chance of being a bug...17:31
tewardooo good point, my TZ is America/New_York, lemme go throw this at my Etc/Utc VPSes17:31
LrdDimwitah, I see17:31
LrdDimwitAside from the fact a friend said the same command worked on another distro (leading me to believe no) I can look it up17:32
LrdDimwit"Daylight Saving Time (United States) 2014 began at 2:00 AM on17:32
LrdDimwitSunday, March 9"17:32
LrdDimwitand it also began at 2 AM on March 10, 2013 (which is another date I listed as broken)17:33
hggdhLrdDimwit: what is your TZ?17:34
LrdDimwitCalifornia time17:34
tewardhggdh: it's a TZ issue17:34
tewardLrdDimwit: ^17:35
tewardit works fine when timezone is Etc/Utc17:35
tewardbut when in a specific timezone with DST it doesn't appear to work - looks like it might be timezone related somewhat17:35
teward(this is why I say servers should all be Utc :P)17:35
LrdDimwitit 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 bug17:36
LrdDimwitinterestingly 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:36
tewardhggdh: 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:37
hggdhteward: go ahead, adding a comment that this is TZ/daylight savings-related17:38
tewarddone17:39
hggdhLrdDimwit: usually it is better to check/set times after a certain time (usually I set them all at 12:00) to bypass possible TZ issues17:39
hggdhteward: thank you sir, in your debt17:39
tewardhggdh: or for servers, use all UTC and do the time conversion yourself17:40
* teward is weird that way :P17:40
LrdDimwitthis is my personal dev box.  Our servers ARE all in UTC (and I see now one very interesting reason why)17:40
hggdhteward: indeed. all my servers are UTC17:40
LrdDimwitSo if I used 0300 or 0100 it would have worked?17:40
hggdhLrdDimwit: most probably. As long that this is a valid time in this date/TZ, it should work17:41
LrdDimwitif 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 office17:41
hggdhLrdDimwit: yes, please do so, and comment on the bug (and reopen it if needed)17:42
LrdDimwitwill do.17:42
LrdDimwitThank you for your assistance17:42
hggdhyou are welcome. Thank you for asking (and having the pacience to wait for a response)17:43
LrdDimwiteh, it's IRC.  IRC is asynchronous :)17:44
hggdh:-)17:44
LrdDimwitit'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
hggdhheh17:44
tewardOr, ask us to reopen17:45
tewardhggdh: can normal users go from Invalid -> New ?17:45
tewardI know I can because Bug Control, but can normal users17:45
LrdDimwitit might depend on whether said normal user is the originator?17:45
hggdhteward: yes, they should be able to17:45
tewardack17:45
hggdhBTW, it only worked for me because the machine I am running IRC from is under UTC...17:47
tewardhggdh: right, i tested on my Precise and Trusty VMs (both UTC) so...17:47
tewardmeh17:47
=== PrincessAuv is now known as Auv
=== Auv is now known as PrincessAuv
=== ara is now known as Guest47294

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