Yes! Jarsto, I think you're right! Using a Unix time converter, I checked several books in my db and all the timestamps looked right.
So I decided to throw caution to the wind (unusual for me, I know), and did the following:
- Noted three books on my T1 with a "new" badge
- Opened my database and confirmed that those three books with "new" badge had "null" value in the reading_time column
- Copied the timestamp from the most recently read book: 1342846307263
- Replaced the "null" value on the three "new" books with: 1342846308263, 1342846309263, 1342846310263 (I decided to adjust the seconds, as I'm leery of those 3 extra digits, and I based it on the most recently read book to "pretend" that I opened these books after my most recently read book)
- Held my breath, copied the revised database back to my T1, and loaded it
Result:
- "New" badges on above three books disappeared!
- Above three books also appeared at the top of book list when sorted by "Last Read." The books also show "Last Read" times that correspond to the Unix numbers I input.
Based on this, it seems the "new" badges are indeed triggered by a "null" value in the reading_time column and the timestamps are Unix Time plus 3 extra digits (milliseconds?). It also appears that you can remove the "new" badges by inserting your own timestamps, BUT as Rupor noted, the full ramifications of doing so are unclear and possibly dire.
Finally, I'm guessing each timestamp should be unique -- i.e., you can't have opened more than one book at the exact same millisecond, so it may cause problems if you use the same timestamp for more than one book. This makes updating each timestamp more tedious.
Given the above, I'm not sure if it's worth it to remove "new" badges by messing with the database rather than simply opening/closing each book manually. Thoughts anyone?