-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dates in CSV are wrong (signed/unsigned issue?) #59
Comments
Update: Looking into it more, I haven't been able to munge the timestamps back with simple signed/unsigned transformations, so that might not be the issue. |
Got the same problem , tried every format in libreoffice, but can't get any Date/Time. Best regards |
Are you sure your export ran properly? In the CSV I got, I have 13-digit-unix-timestamps - i.e. millisecond-level unix time UTC. I have yet to see one that doesn't match. These came out of
|
@EvilRenegade |
Found |
Hold up. Those are more digits than in the original post. That looks proper. As said: It should be a 13-digit unix epoch, millisecond level. Shave off the last three digits and run it through any unix time converter, and you should have your date. e.g. you would take 1458320669840, erase the last three digits (1458320669) and get Fr 18. Mär 18:04:29 CET 2016. ( If you're using a library that can handle millisecond-level timestamps for unix times, you can also use the stamps directly. |
@EvilRenegade Thanks to you. In libreoffice I can use (with all digits ) -- |
For anyone else who runs into issues, the converter at https://www.epochconverter.com/ accepts unix timestamps at millisecond level, i.e. the export timestamps work without modification with that. |
Detailed description
I tried reading my most recent backup and it works (thank you!) but the timestamps in the CSV output are all wrong.
I'm looking at the
DATE_RECEIVED
andDATE_SENT
fields, and none correspond to the actual times I see in the app (which seem right, according to my memory).Many of the timestamps have a dash in front of them, like they're negative, so I'm wondering if it's a simple issue of interpreting them as signed integers instead of unsigned ones?
Full relevant output
Here's some excerpts (phone numbers have been scrambled for privacy):
and later in the output..
The actual timestamps of those messages, respectively, are:
2016-11-11 4:09:48PM EST
2016-11-13 10:10:35PM EST
2016-11-20 7:33:24PM EST
2017-01-04 2:42:02PM EST
The text was updated successfully, but these errors were encountered: