If you set a regular cover date of say 3/1/2013 and then switch to fuzzy dates the month jumps to February 2013, it is always a month earlier when switching, switching back from fuzzy to exact is off as well, if the fuzzy month is the current month the day will set to the current day and if the fuzzy month is another month the day switches to a random day.
Ok I'm bringing this back since fuzzy dates are still buggy, now specifically it is when trying to set the fuzzy month to February, example: Karakuri Circus #4, 8 & 13, every single issue that needs to be set to February will not allow me to, if I set it to February XXXX it shifts to March XXXX on refresh, when working with other months that shift there is normally a work around if you switch to a quarter instead of a month, save, then edit and change to the needed month it will work but that isn't the case with February usually.
@rorie: got another weird fuzzy bug, this issue, the fuzzy date is supposed to be September 2013, it displays October 2013 but if you edit the page it shows as being September 2013 sometimes and October 2013 other times, flipping to quarter and back doesn't fix it.
Update: It isn't just that issue, it is every new release that was added this week that has an in store date of July 31, 2013 and a cover date of September 2013 if it was later updated after initially being added i.e. when originally created they used September but once someone edited the page it shifted on its own and got stuck so some buried logic is shifting it up because of the July 31st bit. Can you please have someone look into this today as it is making dozens of pages inaccurate.
I don't get why a simple date field is such a constant source of problems >.< there's gotta be some logic added in that keeps causing them.
@rorie: I was wrong, new fuzzy date bug, we can't switch from a regular date to a fuzzy date anymore, doing so and saving produces the "No changes made" dialog, to change from a regular date now an editor has to go from regular to a quarter, save, edit, quarter to month, save. Pretty bad.
Tested a theory to see if submitting other changes at the same time as changing from regular to fuzzy would push the edit through and it does not, the other edits will go through but the cover date will stay regular.
It will change however if you add or modify the In Store date in the same submission as changing the Cover Date from regular to fuzzy.
I have another issue. It seems that if you edit from an exact date to a fuzzy date it says not changes have been made. And upon refresh still shows the exact date. Also when you do click fuzzy date it is still reverting back to a prior month instead of using the existing for the exact. (exact says March 1, 2013, hit fuzzy and goes to February 2013). The only way to get it to go to the correct fuzzy is to edit it once with the wrong month (which then also does as Pika mentioned rolls back a month choose February 2013 get January 2013), and then edit it again to set the correct fuzzy date.
@rorie: please please please make this a priority first thing Monday, every single time someone edits an issue that has a cover date it is messing it up and a lot of editors do multiple edits on a single page so it's not always going to be as simple as adding one month to fix something.
edit: and it's even worse that very few people have even noticed, so far I only know of two editors other then myself that know.
So far the easiest but maybe not the cleanest way to edit these pages is to edit once set the date to any day from that month and save. Then edit again and click fuzzy. This seems to work properly and doesn't slip back one month and doesn't give the you have not made changes to the page error that you get when editing a page with a date at the 1st of the month. Problem is not only do you have to edit the page twice but of course the points are inflated from each edit.
@rorie: ok problem was fixed for a few hours but some late afternoon push made it worse then before, it isn't making inaccurate data but it is annoying, now I can't switch from a regular cover date to a fuzzy date period, month or quarter, both show up as no changes. Trying to force it through by deleting the in store date doesn't do it either.
Edit: only way to switch to fuzzy is to delete the regular date, save, edit and create a fuzzy from the empty field.
I am glad it doesn't slip anymore when the day is set to the first day of the month i.e. if the regular date is 1/1/2011 and it was changed to a fuzzy date it would slip to December 2010 but if the regular date was 1/2/2011 and changed it would be correct at January 2011, that was super annoying.
@pikahyper: Hmm, I'm still not having the same problem as you - I can switch from exact to fuzzy on those pages, although if I'm changing from 1/1/2008 to January 2008, I have to flip it to February first, save, then flip it to January to save it. It looks like the system doesn't seem to regard just hitting the button to switch from fuzzy to precise, or vice versa, as a real edit action. I'll see if that can get fixed.
@rorie: oh oh I think I figured it out, the site doesn't see a difference between 1/1/2011 and 1/2011 that's why switching from a regular date set to the first of the month to a fuzzy doesn't register as a change but changing from 1/2/2011 to 1/2011 does register.
@pikahyper: Yeah that's the same issue I'm having, highly annoying that you have to edit the page twice now instead of it just recognizing that going from 1/1/2013 to 1/2013 is a different date.
And now that it's mentioned I wonder if this has something to do with the story arc issue. I was about to post a new bug for it like you mentioned, and I almost bet this is a factor, when it sees two comics released say in January 2013, and if by what we were told and it goes by the fuzzy date, it would assume the date is coded as the 1st of the month for both comics. Now the question would be if you set a date to 1/8/2013 and then save it as fuzzy, would it still assume its 1/8 and show the fuzzy, or is it coded in such a manner that is will revert to 1/1 and show the fuzzy?
@wmwadeii: I put in a request for story arcs to change from cover date to in store date a while back, I think it is still on the to do list and hopefully will happen eventually as it would make things much more accurate..
As for the fuzzy changing I've never worked on a site with so many issues with something as simple as dates. From what I can tell though there is extra logic coded in that is causing the issues, I believe that the database is storing dates as a regular XX/XX/XXXX date at all times and that when you switch to a fuzzy date another field is updated labeling it as a regular date, fuzzy date or quarterly date and then programmatically the site is making it display how we see it, the reason I think so is that if you change something from a regular date of 8/11/2013 to a fuzzy date and save and then edit the page again any time later and switch back to a regular date most of the time it will revert back to what the original date was so in this case 8/11/2013, that tells me it is storing the full date and something else is making it output/display as an alternate view and if the cover date never had a regular date it defaults to the first of the month which would also make sense if going from no date to fuzzy date auto completes the day as the first.
@pikahyper: I just posted the bug report for the story arcs with some testing I did. What you mentioned about changing the date to an exact date like 8/11/2013 saving, then changing to fuzzy saving, then going to edit again and reverting to 8/11/2013 doesn't work anymore. If they get that working again it would probably solve the story arc issue as well.
@rorie: looks like all but one of the date problems is fixed, we still can't change from a regular date set to the first of the month to a fuzzy date, it doesn't register as a change so you have to change it to another day of the month, save, then edit and change to a fuzzy so the point reward is doubled. Since we didn't use the day on the old site the database filled in all the empty day fields with 1 with the relaunch so the most common existing dates are all set to the first of the month and can't be changed to a fuzzy without the double editing.