Bad dates due to timezone after recent update? [will be fixed in a future update]
I'm using 1Password 4.4.1 (Agile Web Store).
I put my passport information in the program back in 2012.
However, today I looked at my passport information, and the days are off by one. The day is one earlier than the actual date.
I assume that this is some sort of time zone issue. If I change my time zone to one hour in the ahead (to CDT from CST) and refresh the information, the dates are correct. (I'm in an a country that does not have DST)
I don't know if this issue is due to a change from the most recent update that I applied earlier today.
Comments
-
Gee, I thought that issue had been fixed sometime ago. But I haven't shifted time zones since I found the same thing during the early beta testing of version 4. If it's new to the version that arrived today (4.4.1), it's a reversion.
Edit: To check this out, I went into my system settings and turned off automatic detection of the time zone, and then I shifted the time zone two zones to the west. I restarted my Mac and reopened 1Password. Sure enough, my birthday and the issue and expiration dates for my password show as one day earlier that are accurate. This is a problem.
And while returning my timezone settings to automatic, I discovered that no restart is needed to produce this effect. If I leave my passport record open in 1Password, the dates revert to their correct values if I switch away from the record and immediately return to it.
And, my birthdate in the record for my Driver License also shifts in the same way. And my birthday in my Identities record too. I'm beginning to suspect the bug affects any field with an exact date.
0 -
Here is a composite pair of screen captures showing the Driver License record in the Demo Vault. My local time is Central Daylight Time, and if my own records the guide, that version (on the bottom) shows the correct birthdate. The top panel is Pacific Daylight Time, two zones to the west. The date is one day earlier.
0 -
I will note that I'm in the same time zone that I was in when I originally created the record (Central Standard Time UTC -6) and I'm in that same time zone right now. However, at the time I created the record, there was no Daylight Saving Time in North America, and while there is so now. (At both times, my system setting was set correctly in a location that does not observe DST.)
To be slightly pedantic, The proper time zones for the shots in the previous post are Central Daylight Time (UTC-5). and Pacific Daylight Time (UTC -7).
My hope is that when the issue is fixed it won't fix the dates in my vault to be one day off.
0 -
To be slightly pedantic, The proper time zones for the shots in the previous post are Central Daylight Time (UTC-5). and Pacific Daylight Time (UTC -7).
Gee, of course I missed that while focusing on the underlying issue. You are, of course, correct. :\"> I wonder what will happen if I edit the image at the source... (I did that and it looks like it comes through to the forum to me. Thanks for the correction!)
By the way, I have not noticed that the switch from Standard Time to Daylight Savings Time has affected the birthdates in my records.
0 -
I wonder if the date is being encoded or interpreted as being 12 midnight Eastern Standard Time (UTC-5). That would cause people in the Central Time Zone (in US/Canada) to notice the issue between March and November each year.
0 -
In my opinion, the date shouldn't be subject to any other interpretation than that my birthdate is as I entered it! Same for issue and expiry dates. This isn't a calendar application.
0 -
OK, I just moved my iPad five time zones west, and it made my birthday shift to one day earlier than actual. I did not cross the International Dateline, as if that actually mattered. And it was a physical change of location, not a settings adjustment. This is not just a Mac issue.
0 -
I have just discovered what I consider a significant bug, and I am rather upset. Actually, I'm very upset.
The example I am using is the dates fields in the passport template. I was just filling in some forms for travel for my children, and I have always used 1Password for storing these details.
I noticed that my daughter's date of birth was one date earlier than it really is (at least that's a field I know!). I then looked at my birthday on my passport record, and it was also one day earlier.
I then changed my time zone (I am currently visiting the East Coast USA) back to Central Europe, and voila... the dates went back to normal.
Except, not quite, because I when I first noticed the error with my daughter's birthday, I corrected it. So, now when I change time zones back and forth, the DOB, Issues, and Expiry dates of the whole family's passports change by a day, except for my daughter's birthday.
AND... this is not related to the difference in zones being different dates. I did this at 15:30 EDT, which is 21:30 in Europe, so when I changed back and forth between the two zones, today's date remains the same.
You an imagine my upsetness (is that a word)? I have trusted 1P for a long time, and I don't carry my children's passports with me... they are locked away at home. But now, I have no idea which issue date and expiry date to use. I know you are not liable for anything, but I've had to get my in-laws to travel 10 miles to my home to retrieve the passports to get the data.
I ALSO TESTED THIS NOW WITH MY iPHONE. SAME THING!
Well, not quite... most of the dates change with the time zone, but one doesn't change... even though it does on my Mac.I'm guessing it might be related to when the field was last updated and which time zone I was in.
Both apps are latest released versions (Mac is the NON App Store version), and I sync with Dropbox.
It is astonishing that a programmer would not have understood this is a FIXED field... my Birthday can NEVER change! Nor, for that matter, the date a passport was issued. Maybe I accept that it wasn't found in testing... but how did this ever get programmed in the first place?
I don't imagine your fix will include a way to correct the records? It would be good if it did.
Regards, Nic.
0 -
Several others of us have reported this same bug. I once thought it was corrected, and maybe it was. But if so, it has reverted to its bad behavior. I believe I first noticed it about a year ago while beta testing for version 4 was still going on, but before the formal release.
These dates should not rely on time zones at all. They are fixed data and remain the same, regardless of where in the world a user happens to be at any given time.
The same thing happens in entries for drivers licenses.
0 -
Hi @fletchni,
Thank you for reporting this bug. I've merged your posting, and @hawkmoth's reply, with an earlier report and discussion of it.
I do apologize for the inconvenience this has caused you. It will be fixed in a future update, although we can't promise when that will be. I've made a note to the developers that you would also like a way to repair items affected by this bug.
0 -
I just noticed this bug in 1Password for iOS and I am on 1Password
Any update on when this might be fixed? I would have expected a known bug like this from 1P4 to be fixed in 1P
0 -
I understand that it probably seems baffling that we're still fighting with this but it genuinely isn't because it's being ignored. The bug relates to a design decision and the tricky part isn't fixing it, but trying to find a way that doesn't break compatibility with all previous versions of 1Password. It is still being puzzled over and the developers are still hoping for a solution that still allows all of our users from 1Password 3 and onwards to work alongside the most current version.
0 -
Hi folks,
This has been fixed in the latest iOS beta and will hopefully be making it into stable releases of all affected products soon. :)
0
