Birthdates off by one day in 1Password 5. [Fixed in Version 5.3]

Winnie

1Password originally stored date fields as math values (seconds from 1 January 1970, GMT) that would need to be calculated to be properly displayed. The math happening behind the scenes to calculate and display these dates in your local timezone wasn't working quite right.

We're hoping to re-code these fields as static date fields, but unfortunately that requires a lot of coordination across all 1Password platforms. For now the math should be working properly. The only issue you could encounter is when traveling to a different timezone.

jimthing

You say fix coming on OS X in 5.1, but many of us have one or more of our Macs not yet on 10.10 Yo yet (for software or hardware considerations), so are not able to use a 5.x version.

So can you clarify whether this bug will be addressed in the previous version many are still using on those machines (4.4.2, I believe?)? If not, are such users still going to have to deal with it, and will this therefore not fix the bug for such users?

Ben

Hi @jimthing‌

Currently this is only being fixed in the latest version of 1Password.

Thanks.

yellowlobo

Glad to hear there's a fix coming. I just checked my family in for some upcoming flights and used their passport info stored in 1Password. All of the passport issue and expiry dates were 1 day out which could have caused some serious inconvenience at the airport! Luckily I noticed at the last minute before submitting.

hawkmoth

The time zone dependence that remains after this fix is still a big problem. An expiration, issue, or birthdate is a fixed value, not one that depends on what time zone the user is presently occupying.

jimthing

Don't understand the decision to only support 5.x on such a major fix – it effectively makes the app dead to users who have machines that have to still use a non-Yosemite version, due to their work commitments.

Dumb, plain and simple, from your users' point of view. The OS has only been out a couple of months, so to expect every user to be able to just jump straight on board with using your properly working 5.x software version only with such a new OS seems completely ridiculous and shortsighted. 4.x should be updated as well.

Ben

@jimthing‌

I understand your perspective but we simply don't have the resources to maintain two branches of the Mac product. Also I'm not saying that we are definitely not ever going to fix it for 4.x, only that right now we're concentrating on 5.x.

Thanks.

@hawkmoth‌

Yes, I agree. I'm sure our developers will look into that as well, but it may not make it into this initial fix.

0p3raGh05t

So you are coming out with a temporary fix that will not really fix anything if one happens to change time zones, right? You'll only corrupt my data when I travel, right?

Good to know.

Megan

Hi @0p3raGh05t,

I apologize for the trouble here. We know this is not a final solution to this issue, but it is our hope that this fix will alleviate some of the frustration while we work on the underlying issue.

As has been stated earlier in this thread, the full solution for this time-zone bug requires a lot of coordination across all of the platforms that we offer 1Password on: essentially we have to re-write the way we define dates within the database. I'm not a developer, but if I've learned anything by discussing this issue with our iOS team it is that dates can be a difficult thing to code. We can't do this on one platform at a time or it will cause even more complications.

This fix is a priority for us, as we know that it has been affecting users for a while now. In the meantime, I would suggest storing your dates in a text field within the entry if you are planning to do any travelling.

I know that this isn't a proper solution, but I hope this helps while our developers work to get this bug properly squashed!

hawkmoth

I'm not a developer either, but I wonder how hard it would be to change the date fields with all of their connections to calendars and time zones, to plaintext that would never, ever change, ever, unless the user changed it. I think that's what we need here. No calculations, no dependencies on anything, other that what the user entered.

MrC

Remember, what is Exported (say, via a 1PIF file) needs to be Importable too. If you change the various date field formats, your choices are:

1. Export the Plain Text (in which case it is not Importable), or
2. Convert-on-Export to the currently expected time value format stored (in which case you have the same problem as exists now)

The 1PIF and other storage formats used are essentially Data Structures, and they cannot be changed singularly (all importing and exporting code needs to be updated in lockstep).

Ben

Hence part of the reason this is a much more complex problem than it would appear to be on the surface. :) Thanks for chiming in here, @MrC!

hawkmoth

I give up! What seems plain and simple obviously isn't.

jimthing

Can MrC (or someone else) explain your points a bit more in layman's terms, perhaps with examples. I'm not quite sure most users would fully grasp the "import-export" you talk about in both those points...

Eg:
1. why not importable?
2. why same problem as now?

MrC

Quick reply, but please note I don't speak for AgileBits.

1. Existing 1Password programs already installed on user's systems expect the date data to be in a particular format, for example, the numerical value representing the number 1417593179. If the format is changed, for example, to a sequence of characters such as Wed, 03 Dec 2014 07:52:59 GMT, existing installations will not know about the change, and will read in nonsensical data. In other words, the data is no longer compatible between 1Password versions.

2. The two date values above do represent the same date; they are in fact just two ways of encoding that particular date. However, due to time zone issues, different operating system library code, and in some cases ambiguity at daylight saving time boundaries, conversion from the numerical value to the character value can be problematic across different platforms.

The problem is a little difficult to explain without a good grasp of how data is encoded both in storage and in computer memory while being used.

jimthing

Ah, thanks, that makes for a better understanding to us punters of the kind of ideas being grappled with by 1P's coding team.

Sounds a right pain in the neck for them, to be honest!
–––

As I suggested before to other users, use the Notes or a freetext box temporarily to keep the date in as a workaround, eg:
"Notes
Passport expires: 24 Jan 2018. "

Ben

Thank you again for the assist, @MrC. An excellent explanation.

stlei

Dear Agile Team,
I have experience a strange sync behaviour with my iOS Device.
The day of my birthday (14.) is correct on my Mac. The synced entry is showing the (13.). When I try to change it on my iOS device I can do it, but after saving it is still the 13. (On my Mac it's still correct). Really weird. At least the App doesn't make me older :-)
Any ideas how this issue can be fixed?

Regards

Stephan

#

Mac: 5.1-Beta14
iOS: 5.1.2

Ben

Hi @stlei‌

I've merged your thread with another on the same subject. Please see above. :)

Ben

fletchni

Hi... just discovered I can no longer create a case, but need to use this forum (a subtle piece of feedback)!

I had reported earlier this year a bug with date fields (#FNW-96854-957), which appears to still be continuing.

The case in question are records for my and my family's passports (issue date, expiry date, dob [it's the wrong dob that alerts me to the error]).

I am certain this is to do with time zones (yes... we have passports, so we use them to travel). I also travel a lot for work, and am often in the US or Asia (I live in Europe).

If you can't fix this by now... how about just making them text fields (I have now added extra fields - which of course are always text - because I can no longer trust 1Password)?

BTW, I also noted that several of the date fields had been DUPLICATED! I'm pretty sure it couldn't have been me, because it was in the main section of the passport record... and in any case we can't create custom date fields.

All dates in 1Password will ALWAYS be static... so why not just change the design, and then the bug will be gone. No real dates in the database!

Thanks, Nic.

FlyingGS

Same problem here. I corrected it manually but indeed dates of birth where duplicated and off by ±2 days on most passport and ID records!! I may have missed some but indeed this is a serious problem that affects the integrity of the data stored. Like fletchini I would love to see an update on this critical issue.

hawkmoth

The AgileBits folks reported a few weeks ago that they have squashed this bug and that the fix will come in the next release. They did not, however, say when that release would be, and so far, it hasn't appeared.

FlyingGS

Thanks for the update hawkmoth.

fletchni

I was told this was "squashed" back in July... I'm still waiting!

Drew_AG

Hi @fletchni and @FlyingGS,

I merged your thread with this discussion about the same issue. You can find more information about the problem by browsing through previous messages, or take a look at this one.

Thanks!

Yogie

Hi,

I do have an issue on my iPad, I was just entering my passport data. All dates like issue date, expiry and birth date entered correctly, when I hit save all dates are displayed -1 day. So entering for example 16.05.1970 it's getting 15.05.1970 and this value is also the synced to my Mac. When I enter the correct data on my iPad again it's getting the same result -1 day. Changing it on my Mac and sync it to my iPad works, if I then go into the record on my iPad and touch the date it's again changing (- 1 day).

Cheers
Joerg

Stephen_C

This is a known, and complex bug, with which AgileBits is currently wrestling. There's a very long thread about it on this forum and it's probably best to start with this post in that thread if you want to know more.

Stephen

Yogie

Thanks! As I searched it seems I used the wrong keywords or didn't saw the thread - sorry!

Yogie

Still have it in iOS App V. 5.1.2 and it's on all date fields!

Stephen_C

@Yogie‌ I have merged the other thread you started with this one to keep all posts on this topic in one place.

Stephen