In Android app, why is a birthdate showing up in Unix epoch format?
I have a birthdate in one of my 1PW items, which shows correctly in the Mac app, but shows as a Unix date code in the Android app. It is the correct Unix date code, but not what I want to see. The birthdate is prior to the Unix epoch date of January 1, 1970, so I'm thinking maybe there's a coding error for how dates prior to that are represented. The date & time settings on my phone are the automatic type, using a standard U.S. date format, so I don't see them as the cause. Has anyone else come across this problem?
1Password Version: Mac 5.3.2 & Android 4.5.2 (Agile Web Store)
Extension Version: Chrome 4.4.3.90, Firefox 4.4.3
OS Version: OS X 10.10.5
Sync Type: Wi-Fi
Comments
-
Peri, it's still a problem. I did as you suggested, and I even tried deleting the field on both the phone & the iMac, then adding again on the iMac. I also tried exiting and re-opening 1PW on the phone. But when I opened the item on the phone, I got an "invalid date" popup, and the date was still in Unix epoch format. Then I tried entering the date on the phone, and then syncing, and that worked. However, my intention is to do all my data entry on the iMac, so I still see this as a problem. (The Android app updated when I logged in today, so now I'm at the latest, 4.5.3.)
0 -
Thanks for the update, @Bob_SF. I think that we'll need to reinstall and reconfigure sync on Android in order for the newly changed dates to be fixed there.
First things first, please make sure that all data from your Android is synced over to the Mac, to prevent any data loss. Then, update the dates in all items that contain a date field manually using 1Password for Mac. Once all the dates are fixed, go ahead and uninstall/reinstall 1Password 4 for Android and reconfigure WiFi sync. That should do the trick!
Please let me know how it goes!
0 -
I put this aside while dealing with a massive cleanup of my accounts, updating a lot a passwords, and entering a ton of data into 1Password to set it up. But tonight I reinstalled the Android version of 1PW and synced. The Unix date problem remains — in the date-of-birth field for a Driver's License. Again, the date I entered is prior to the Unix epoch starting date. It shows up correctly in the Mac version of 1PW. I did a little testing in the Driver's License format and have verified that dates beginning January 1, 1970 sync to Android with no problem, but dates ending December 31, 1969 and prior show as Unix epoch dates. I also created a secure note that contained a date field, and entered December 31, 1969 into that field — which caused the same sync problem. My guess is that the code for handling dates in the Android app contains an error.
0 -
Thanks for giving that a try and for the update! With this added information, I was able to reproduce the issue you're describing. Indeed, items with dates prior to January 1, 1970 sync correctly, while earlier dates show up on Android in Unix time.
Curiously, though, the same problem doesn't exist when syncing with Dropbox. I was only able to reproduce the issue when syncing using WiFi.
At any rate, I've gone ahead and reported this to our developers. Hopefully this will be an easy fix, and they'll be able to get it resolved in the near future.
ref: OPA-639Let me know if you have any further issues. Thanks again!
0 -
So the sync method affects the outcome. That's unexpected, but helps to focus on the problem. As mentioned earlier, I am able to enter a date on the phone (even a date prior to 1/1/70), which then is rendered properly. I just can't sync a pre-1/1/70 date to the phone without getting the Unix epoch result. I'm sure your developers can find the cause pretty quickly. Thanks for the followups.
0 -
I just noticed something else: in the Driver's License format, the address fields are not syncing correctly at all. Instead of street address, city, state, ZIP, and country (in the Mac app), I get province/state & country in the Android app — the street address, city, & ZIP do not show up. And if I create a secure note that contains an address (using the address format in the Mac app), the note shows up empty in the Android app. So maybe there is a broader problem?
0 -
I'm not able to reproduce this second issue, @Bob_SF. In my Driver License items, I have my address line (123 Fake Street,), and the State and Country fields show my state and country. Also, in my other items with addresses (like Identities for instance), my address shows up as it should.
Could you please create a test item on your Mac (with dummy data) that matches the other items with address issues? Then please screenshot the template so that I can see how I should be setting up an item to test this.
0 -
OK, here are images for two types of entries, a Driver's License & a Secure Note. For each of these, there are 2 views on the Mac (in edit mode & in saved mode) and a view of the synced result on the Android phone. As you can see, the results are different for the two addresses. And on the phone, the dates are in Unix epoch format.
0 -
Thanks so much for the screenshots, @Bob_SF. :lol: I see exactly what you're describing now, and was able to reproduce this issue as well.
I've tested this in every category, using both Dropbox and Wi-Fi sync, and found that this bug is reproducible in every category except Identities. Address fields sync properly in Identity items.
It seems like this issue is related to custom fields, but I'm not a developer so I'm not sure. I'll let the developers handle that part. :)
At any rate, I've filed a bug report for this issue as well. Hopefully we'll be able to get both of these sorted out soon. ref: OPA-642
0 -
Peri, thanks for your further testing, and for filing the bug report.
0 -
No problem! Thank you for helping us uncover this bug, and let us know if you find any other issues. :)
0
