starred/sms-backup-plus-jberkel

Fork 0

mirror of https://github.com/jberkel/sms-backup-plus.git synced 2026-04-25 17:05:59 +03:00

[GH-ISSUE #94] Restore marks restore time not previous sms time #80

New issue

Closed

opened 2026-02-26 00:36:12 +03:00 by kerem · 9 comments

kerem commented

2026-02-26 00:36:12 +03:00

Owner

Originally created by @antwonw on GitHub (Dec 12, 2010).
Original GitHub issue: https://github.com/jberkel/sms-backup-plus/issues/94

Had to factory reset my phone. I wanted to restore my text messages from before. I restored and now all my txts list the date and time they were restored on my phone, not the time they were originally received before.

Originally created by @antwonw on GitHub (Dec 12, 2010). Original GitHub issue: https://github.com/jberkel/sms-backup-plus/issues/94 Had to factory reset my phone. I wanted to restore my text messages from before. I restored and now all my txts list the date and time they were restored on my phone, not the time they were originally received before.

kerem closed this issue

2026-02-26 00:36:12 +03:00

kerem commented

2026-02-26 00:36:13 +03:00

Author

Owner

@jberkel commented on GitHub (Dec 14, 2010):

This happens on some phones, but haven't been able to reproduce this locally

@jberkel commented on GitHub (Dec 14, 2010): This happens on some phones, but haven't been able to reproduce this locally

kerem commented

2026-02-26 00:36:13 +03:00

Author

Owner

@antwonw commented on GitHub (Dec 17, 2010):

So this is just a per-phone issue not a global android/sms backup issue? (By the way, I am using the Droid X)

@antwonw commented on GitHub (Dec 17, 2010): So this is just a per-phone issue not a global android/sms backup issue? (By the way, I am using the Droid X)

kerem commented

2026-02-26 00:36:13 +03:00

Author

Owner

@jberkel commented on GitHub (Dec 17, 2010):

seems to be - esp. droid x seems to behave really weirdly when it comes to timestamps - there's a bug in the firmware (probably customised by motorola).

@jberkel commented on GitHub (Dec 17, 2010): seems to be - esp. droid x seems to behave really weirdly when it comes to timestamps - there's a bug in the firmware (probably customised by motorola).

kerem commented

2026-02-26 00:36:13 +03:00

Author

Owner

@madhaus commented on GitHub (May 29, 2011):

I just had the same problem... on the Droid X too. Would the fix recommended for the other timestamp problems also solve this one? I just had my entire system clobbered when I updated the OS and had to do a factory reset. When I restored my text messages, they were all dated today. And here I was hoping that with OS 2.3.3 these issues would have been fixed. Sorry, they are obviously still there, although my messages have been backed up fine.

@madhaus commented on GitHub (May 29, 2011): I just had the same problem... on the Droid X too. Would the fix recommended for the other timestamp problems also solve this one? I just had my entire system clobbered when I updated the OS and had to do a factory reset. When I restored my text messages, they were all dated today. And here I was hoping that with OS 2.3.3 these issues would have been fixed. Sorry, they are obviously still there, although my messages have been backed up fine.

kerem commented

2026-02-26 00:36:13 +03:00

Author

Owner

@EnterSpace commented on GitHub (Apr 10, 2012):

Motorola, in general. 2.3.4 Droid X2 stock, and I have same problem. Backups good, restore all restored out of order and stamped with restore time (although restoring "100" off my 5000 DOES restore the most recent 100, within the threading on phone it is random.) Other software has tracked this down and fixed:
http://android.riteshsahu.com/misc/faqs-about-sms-backup-restore#q21

@EnterSpace commented on GitHub (Apr 10, 2012): Motorola, in general. 2.3.4 Droid X2 stock, and I have same problem. Backups good, restore all restored out of order and stamped with restore time (although restoring "100" off my 5000 DOES restore the most recent 100, within the threading on phone it is random.) Other software has tracked this down and fixed: http://android.riteshsahu.com/misc/faqs-about-sms-backup-restore#q21

kerem commented

2026-02-26 00:36:13 +03:00

Author

Owner

@spectas commented on GitHub (Jun 8, 2013):

Hi, did anyone find a solution for this problem? I am having it too, on a HTC Wildfire. This would be very helpful, as all messages are mixed now.
Kind regards!!
Spectas

Hardware: HTC Wildfire
Android version: 2.3.7
Cyanogenmod version: 7.2.0-buzz
SMS Backup+ version: 1.4.8

@spectas commented on GitHub (Jun 8, 2013): Hi, did anyone find a solution for this problem? I am having it too, on a HTC Wildfire. This would be very helpful, as all messages are mixed now. Kind regards!! Spectas Hardware: HTC Wildfire Android version: 2.3.7 Cyanogenmod version: 7.2.0-buzz SMS Backup+ version: 1.4.8

kerem commented

2026-02-26 00:36:13 +03:00

Author

Owner

@jberkel commented on GitHub (Jun 30, 2013):

All that said, it turns out that there's a workaround. When you insert a message, that sets the thread's datestamp to the time of insert. But when you delete a message from a thread (identified by the "address" field in the "content://sms" provider), it has to recalculate the thread datestamp. So for every thread you stuff something into, stuff another dummy message in as well and then delete it. Which is easy because the insert method returns a Uri that you can call the delete method on. I suspect this is horribly inefficient.

http://stackoverflow.com/questions/6903885/android-programatically-inserted-sms-have-incorrect-timestamp-in-messaging-apps/6911015#6911015

@jberkel commented on GitHub (Jun 30, 2013): ``` All that said, it turns out that there's a workaround. When you insert a message, that sets the thread's datestamp to the time of insert. But when you delete a message from a thread (identified by the "address" field in the "content://sms" provider), it has to recalculate the thread datestamp. So for every thread you stuff something into, stuff another dummy message in as well and then delete it. Which is easy because the insert method returns a Uri that you can call the delete method on. I suspect this is horribly inefficient. ``` http://stackoverflow.com/questions/6903885/android-programatically-inserted-sms-have-incorrect-timestamp-in-messaging-apps/6911015#6911015

kerem commented

2026-02-26 00:36:13 +03:00

Author

Owner

@luckyrat commented on GitHub (Dec 15, 2014):

This used to work fine on my HTC One M7 on Android 4.x but since the upgrade to Android 5.0.1, I experience this issue so can no longer rely on this application.

Perhaps it's still just a case of some (albeit different) phones being affected by this bug in Android 5 but I wanted to mention it here since if it affects all Android 5 phones it might become a major issue in the coming months.

@luckyrat commented on GitHub (Dec 15, 2014): This used to work fine on my HTC One M7 on Android 4.x but since the upgrade to Android 5.0.1, I experience this issue so can no longer rely on this application. Perhaps it's still just a case of some (albeit different) phones being affected by this bug in Android 5 but I wanted to mention it here since if it affects all Android 5 phones it might become a major issue in the coming months.

kerem commented

2026-02-26 00:36:13 +03:00

Author

Owner

@jberkel commented on GitHub (Jun 12, 2015):

I tried this with Android 5.1 (emulator) and could not reproduce. Timestamps are correct there. Think it might be device specific. Closing.

@jberkel commented on GitHub (Jun 12, 2015): I tried this with Android 5.1 (emulator) and could not reproduce. Timestamps are correct there. Think it might be device specific. Closing.