Inconsistent handling of year-only dates depending on value: NOT A REQUEST FOR FUZZY DATES
Join LibraryThing to post.
This topic is currently marked as "dormant"—the last message is more than 90 days old. You can revive it by posting a reply.
Essentially, in the "Date started" or "Date stopped" field, the treatment of a year-only date is inconsistent, due to the vagaries of the PHP strtotime function. Four-digit strings (i.e. years) that PHP can parse as a time -- for all practical purposes on the site, anything from 2000 onward though potentially also including anything from 1900 to 1959 -- will result in the current date. Those that PHP cannot parse as a time - from 1960 to 1999 -- will result in the year that was entered, with today's date. This is not, formally, an LT bug but it is certainly unexpected behavior; either of the described behaviors ("failing" from the end-user's viewpoint and returning the current date with a time corresponding to the year that was entered, or returning the year that was entered with today's date) would be better than having one result sometimes and one the other time.
Relevant posts from the earlier thread are brightcopy's initial diagnosis as a strtotime weirdness here, my link to the documentation describing this behavior here, and a suggested workaround here.
I'm sorry, the first thread I have not been able to argue well, because of my unfamiliarity with the English language.
Or do you mean a thread after they decide what they are planning to change once the bugs are cleaned?
Also one where I wasn't specifically not invited to post :P
I suspect that it is too early for such a thread but... up to the LT guys. And cD did say that once the bugs are out of the way, he is moving to new features.
I also don't think people's thoughts about the issue are changing so rapidly that having the discussion a week or more before the development happens will be a big problem.
When you add a book to Currently Reading, bring up a box for Date Started, auto-filled to today. People can click okay to accept the date, or else change it, or just close the box. There will also be options for "don't ask me this again" and "do this automatically in the future".
When you remove a book from Currently Reading, bring up a box for Stopped, auto-filled to today. Again, you can accept the date, or change it, or just close the box; you can tell it never to happen again, or you can tell it to happen automatically.
Similarly for dates --> CR.
It should be straightforward, editing visible catalogue data, with none of the weird implications about what it means if you stop a book without removing it from CR, etc.
I have no real problem with new features that I will never use, as long as I can turn them off easily, never see them again and continue to work the way I always did.
>19 MarthaJeanne: Yeah, hence the "don't ask me this again" part. Maybe that terminology needs to be clarified to distinguish it from the "do this automatically" option (which also wouldn't show the box again), but I can't think of a better wording at the moment.
And if course, if you do tell it to never happen/happen automatically, there has to be an out-of-the-way setting somewhere to let you change your mind.
Now it would be nice if this were in the Book information box so you didn't have to open the edit book page every time to add a new date to your favourite book.
The timestamp thing is fixed on the development server but I'm testing it a bit more to make sure there aren't any flaws in my logic (never happens).
The FINAL TOPIC ABOUT FUZZY DATES.
(Cue pigs flying, Hell freezing, etc.)