Read dates displaying incorrectly in Android app

The revised Android app book details page is a very welcome improvement. However, read dates are being mangled on display. For example, I saved a book read today, then came back to the book page and it now shows as 06/07/0199. This only happens in the app - I've checked that the dates saved correctly through the website. Not sure if relevant, but the old book details page defaulted to a date format of yyyy-mm-dd whereas the new one uses mm/dd/yyyy.

There hasn't been any updates to the Android App.
Could you be looking at Tinycat or the updated webpage?

Also, what phone, what version of the Android App?

There's been a very noticeable change to the design of the Android app. Happened last week, I think?

I can confirm the date problem. Selecting yesterday from the calendar, everything looked good. By saving the date, going back to the work page in the app, then returning to the edit page, I see "07/30/2022" became "06/07/0198".

>3 aspirit: That's interesting because my Android app says last update was March 10, 2021. Build 1.1.29.

Or maybe it just hasn't rolled to my carrier and my google play store. No update available.

Mine's the same version, if it's 1.1.2 (build 29). But actually look at at the edit screen. The design is completely different than it was a year ago, isn't it? I noticed the change last week.

Huh. That is new. But the edit screen is not the book details screen as listed in the OP, which is what got me confused.
On the edit screen, yes, I can also confirm screwy read dates.

>1 AlfieGloucester: Thanks for the report! Yes, we released an LT2 version of the book-edit page (a soft release), but only within the App. Reading dates are editing/saving fine in the iOS App, so it must be Android-specific.

I've alerted the developers about this and we'll post updates here. Thanks for your patience!

>7 kristilabrie: I use the Apple app and I’m having the same problem.

>8 reader1: Yep. Same on the IOS app. They look ok while saving but once saved they look wonky.

>8 reader1: >9 AnnieMod: Odd, I tested saving mine as well and they were fine.

I'll try again...

>8 reader1: >9 AnnieMod: Okay, they're still fine for me. I'll need more details.

- What device/iOS are you using?
- What version/build of the LT App do you have?
- Can you each give me 1-2 examples of reading dates you're editing within the App that are creating this buggy behavior?
- I assume you're both using the calendars to select your dates, or are you filling them in by hand as MM/DD/YYYY?
- When are you seeing the wonky dates: just after saving and before closing the book-edit page? Or do you have to close out of the book-edit page, refresh, and go back in to see the wonky dates?

I'm having the same problem on my iPhone. I have everything up to date on my phone & have checked the app store to see if there is an update for LibraryThing - there isn't. I am seeing the problem when I try to post my reading dates. I have iPhone 11 with the latest IOS update 15.6. LibraryThing app is version 1.1.0. Using the calendar & saving, the dates are messed up then & after closing & reopening.

>11 kristilabrie: IPhone, all updated OS and LT app.
Using the calendar.
After you press Save, the date gets wonky and stays that way. Reopening the edit page shows them still weird ( June 8, 171 instead of August 3, 2022.

The date looks fine when I open the page with a browser. When I open with the app, it is 171 and when you click on the Calendar, it shows it as 171 as well. So it is definitely something on the new page going weird.

Example: the start date of Five Uneasy Pieces in my catalog.

Same problem here. I'm on an Android (version 7. I'll upgrade my phone soon), and app version 1.1.2 build 29.

>11 kristilabrie:
Example: this book in my catalogue.

I entered the dates manually in the app. I first entered 2022-08-04 in the "date finished" field, even though the field says MM/DD/YYYY, and the date became wonky (the year turned into 0172). The calendar that pops up when I click in the field to edit it is set to June 0172. Editing the "date finished" field triggered a change in "date started", even though I did not touch that field; it is now set to the year 0173 -- one year later than date finished. I then tried the MM/DD/YYYY format (unnatural though it is), since that is what the field says it expects, but that just saves as another wonky date. I hit "save" anyway.

Looking at the edit book page on a laptop, I can see that all three dates are now weird: date acquired, date started and date finished now say 1901-12-13. I only edited the date finished.

Thanks. I'll take a look.
The edit screen did, indeed, get an update last week to make it easier to read/use.

iOS version reported at https://www.librarything.com/topic/343413, but it's the same issue so I'm closing that one for this one.

Okay, this bug should be fixed but since I was never able to reproduce I'll need others' help.

Can anyone, who was having issues with reading dates in the app before, verify that they're okay now? You may need to force-close/restart the LibraryThing App before testing (to make sure a new session has been started).

Thanks for your help.

Mine seem to be fixed now. Thanks!

Looks good on my side. Thank you!

Excellent, thanks all!

My old dates look okay now, but when adding new ones they keep skipping back oddly. When I press a date on the calendar and save, or even before, it skips back a few days. Hm. I tried different ways, but it keeps on jumping. Always a few days backwards.

>21 briarhills: Okay, are you using the Android App or iOS App? What timezone are you using on your device? Can you give me one specific example of a book's reading date/s you're trying to edit, with the specific date/s you're seeing? I'll pass this along to conceptDawg.

>21 briarhills: this sounds like your local timezone might be interfering. Hm. Ok. I'll take a look at it and see if I can replicate.

>21 briarhills:
>22 kristilabrie:
>23 conceptDawg:

Same problem. Just for testing, I tried to set the "date finished" for this book to 2022-08-12 (today). The date changed to 2022-08-10 when I clicked "next" on the keyboard. I then quit the app without saving the data.

I tried again with 2022-08-12, and the date changed to 2022-08-09. I edited the final two digits to 12 again, and the date changed to 2022-08-07. This happens regardless of whether I click "next" on the keyboard or tap an empty area to make the keyboard go away. I hit save, and double-checked on the website: the "date finished" was indeed set to 2022-08-07. I then closed the app, and opened it again to check the "date finished" (on the "edit" screen), and it had changed to 2022-08-06.

The "date started" field remains unchanged -- I edited that field on a laptop a few days ago, when I added the book. The changes only seem to happen to dates altered inside the app.

The app seems to set back the date by a certain number of hours, which sometimes means going back 2 days and sometimes 1.

I'm on an Android, version 7. The app version is 1.1.2, build 29. My timezone is UTC+1 (Stockholm, Sweden), which is fetched automatically from my network carrier. It may be relevant to know that I use a 24-hour clock.

Any update on this?

I can no longer edit records in the app (adding tags, changing collections), because the dates (acquired, started, finished) change as soon as the edit book page opens.

>25 Petroglyph: Bug was never reopened. It may have fallen off their radar

Marking as reopened and will remind conceptDawg about it, thanks.

I have the same problem as Petroglyph.
2022-08-26 changed automatically to 2022-08-23 or ..-20 etc. (Date read)

No update but I am trying some fixes. Hopefully I'll have an update very soon.

Just thought I’d add that I’m having the same issue (start/end date jumping a few days back when trying to set it on the app) on an iOS device.

Look forward to seeing a fix for this.

Same as what vishae, petroglyph, and others seem to see: when setting date it jumps back one day immediately, and as soon as you again touch the screen it jumps back two more days.
LibraryThing 1.1.2 (build 29)
Android 11

Same issue here with IOS and it’s driving me crazy! My last reading start date went backwards 4 days 🫠

The bug still continues (Android app).
It's rather enervating.

Bumping for this member, reported (closed as dupe) here: https://www.librarything.com/topic/346191#7990297

For the last month or more, the dates for “Data acquired” and “Date read” changes when ever I’m in edit mode on the app. I chose a specific date fx 26.11.2022) then when I touch anywhere else on the screen or click save, the date changes 1 day back (25.11.2022). If I tap any random place on the app while still in edit mode, the data changes again 1 day back, even if the cursor is no longer in the date field. It will keep going back one day, every time I touch the screen.

If I correct it on the website, the app does not sync up for the specific field.

I have the app on both an iPhone 13 and my iPad. Same problem on both devices when I use the app.

Another example. On the website I chose to edit a book, enter a date (01.12.2022) for finished reading. I save. All is fine. I open the app, and choose edit, the date is now 30.11.2022. I correct the date and save. It saves now as 29.11.2022. I place my cursor (finger) any random field or place on the edit site, every time it changes back one day, 28.11.2022, 27.11.2022. Back on the website, the date is still the 1.12.2022.

So odd and frustrating too :)

Bumping with another report from a duplicate bug:
https://www.librarything.com/topic/347046

Another report of this issue from a member: https://www.librarything.com/topic/100305#8025179

I've stopped editing my books on the app entirely because of this bug. It's definitely annoying.

Bumping this again, after receiving another report of this bug via email. The member in question reports the dates entered being changed to a few days earlier than what was entered. He is using the Android app, and the problem occurs both when initially adding the book and when attempting to edit it afterwards.

Another data point.

Whatever it is that causes this date-altering behaviour affects imports as well. I noticed this yesterday while importing records on another account, but I was too busy cataloguing to look into it.

So, using the sample csv, I imported twelve dummy records, each with title, author, date, tags, date read and page count. The other columns were left empty.

Date and page count were imported as-is, which is the desired outcome. But the "date read" column was consistently different from the source dates. Here is a screenshot:



Whatever the final digit is -- year, month, day -- it ends up as one less than the source data. For "Test 2", that means a change from the first of August to the 31st of July.

How many users have had their imported data improperly altered because of this bug?

Please, please fix this!

Bump.

At the moment it mostly goes back for 4 days (at least on my mobile). Still so annoying.

I am wondering if it's worth collecting the normal timezone for bug reporters. For me it's GMT+10.

I ask because there was a long-standing bug in Windows Media Player where the Album Release Year was constantly off by 1 for many users. It turns out that this was because the year was stored in 31-Dec-Year and anyone outside of American timezones had a rollover into Year+1. My intutition is that there might be a related issue that is being repeatedly calculated as the field is touched, forcing the date to regress in time.

I'm GMT+1.

I am pretty sure this is not actually a time zone issue but actually an issue with the date widget on the new version of the book edit page. We are looking into it.

>45 knerd.knitter:

Is that widget involved in adding imported books to a user's catalogue?

>46 Petroglyph: No.

>47 knerd.knitter:

Does that mean that the date changes for imports (>39 Petroglyph:) are unrelated to the date changes in the app? If so, I'll open a separate bug report.

>48 Petroglyph: yes, that is unrelated and should be fixed.

>48 Petroglyph: There may already be a bug report for that, if I recall correctly... (looking now)

>48 Petroglyph: So https://www.librarything.com/topic/343567#8089512 was fixed on March 9, but could you check and see if there's still any issues there, or check during your next import? Please reopen that thread, if needed.

I've been having this issue as well, I actually recorded the screen the other day as I tried to set the date to show how it jumps and make a bug report... and then found it was already previously reported. So not sure if the video would be needed or not.

One thing I noticed is the date displayed in the field is not the same as shown in the date picker. By that, I mean if I select March 23, 2023 as the date, it rolls back to March 21, 2023 in the field, but selecting the date picker shows March 22, 2023 selected. Whether I make a new selection or not, once I move away from the date picker, the date rolls back another 2 days in the field. If I check the same book entry via the LT website, the date will be one day ahead of what's shown in the app, matching what the date picker shows as selected.

>51 kristilabrie:

The import bug seems to have been fixed -- the dates from a quick trial import made it through the process unaltered. Thanks!

Hi, just bumping this topic as I'm having the the same bug ('date changes') in Sept 2023. Using the Android app, v.1.1.3.

As described in >38 AbigailAdams26:

For me, the date change is dependent on where on the page I press. Pressing 'save' pushes the date back by two days.

Same here. I like to use the app for small, quick changes to my library, such as adding a reading date the moment I finish a book. Or adding a private comment later, which is also not possible because all dates would mess up. Having to open the browser each time is quite inconvenient. And this has been going on for more than a year now.

Just bumping this.

I’d like to be able to update my “date finished” on the app, but currently the app is unusable with the selected date changing when you exit the selection.

Can I also suggest the topic name be changed to reflect that this bug exist in both the iOS and Android version of the app?