search

j256 / ormlite-android

ORMLite Android functionality used in conjunction with ormlite-core
http://ormlite.com/
ISC License
1.59k stars 367 forks source link

SimpleDateFormat doesn't read MS correctly in Android 5.0 and zeros milliseconds for date fields #41

Open Diederikjh opened 9 years ago

Diederikjh commented 9 years ago

In my project I have noticed that when writing date fields the second fractions are written as a string that ends in .000321 for Android 4.x devices. This is when writing a java.util.Date field, so only goes to MS accuracy. Uses default ORMLite date formatter.

On Android 5 however, the dates are written as .321000. This is with the same version of ORMLite (4.48) and both targeting Android SDK 19.

From what I have read the yyyy-MM-dd HH:mm:ss.SSSSSS format that ORMLite uses as default for dates behaves differently for milliseconds on Android 5.0.

Obviously this now breaks compatibility for my users that has upgraded to Android 5.0 (at least all the MS fields now revert to zero, this breaks a unique constraint on my data on an update, for rows created in same second.) The only workaround that I can think of is to change all the date formats for my fields to be SSS second fractions, and upgrade my db to string replace all my date fields that contain .000 with . (Fields that are already saved as .321000 (and passed constraints) will still read correctly, so should need no update.)

j256 commented 8 years ago

Sorry for the long delay. Wow. Time under Android has been a real problem to keep up with. I've noted for some time that the SSSSSS should have been SSS but to change this would complete break backwards compatibility. You can certainly specify your own format although I'm not sure what .SSS would do with .321000 or .000321.

Maybe the right thing to do here is to support a persister that extends the DateStringType and sees if the date is a .SSSSSS and handles it but also handles .SSS and writes new dates as .SSS.

Comments?

Diederikjh commented 8 years ago

That will probably work for backwards compatibility. My only worry is the performance impact of doing the check on each read?

From what I've seen the reads of .321000 reads as .321 and 0.000321 reads as .000 when the date format is set to .SSS.

My solution to this was to simply use .SSS for all my date fields and upgrade my DB to the new format (always fun to write string manipulations in SQLite)

j256 commented 8 years ago

The detection of the 6 versus 3 digits and the position of the zeros is nothing compared to the work needed to convert the string date into a java Date. I'm going to add it as a type.