Signing back into the Community for the first time? You'll need to reset your password to access your account. Find out more.
Forum Discussion
Solved
[Bug Report] Dates with year 3000+ show as 0
- Add a Date field to an item in the 1Password client
- Set the date to year 3000 or beyond
- Save the item
- View the field in the saved item
In my clients all such dates which I tested show the entire value of the field as "0"; that is, the date, not just the year, is "0".
It should show any date which can be set.
Tested on clients on three Linux platforms: Android, Ubuntu and NixOS*. Observation confirmed in Chrome extension version 2.19.1.
Note that this is not an invitation to speculate on circumstances in which dates may be valid, applicable or useful, nor how this kind of thing is a symptom of the kind of poor programming which kept me in the office tomorrow twenty-four years ago.
*[The required category options include just "Linux" and "Android", but nothing for desktop, mobile or or all clients.]
PS. The rich text editor applies common markup for _italic_ but then fails to render it when a footnote line begins with an unescaped asterisk (*).
1Password Version: 8.10.23
Extension Version: N/A
OS Version: Various
Browser: N/A
Hello AJCxZ0! 👋
Thank you for reporting this! Our developers are aware of an issue where dates that include years higher than 3000 aren't displaying properly in the 1Password app. An internal work item is open in our backlog to investigate this further and get it fixed in a future version of 1Password.
Out of curiosity, is there a practical reason why you need to enter 3000 or higher as the year? Or was this just the result of testing the app? I'm asking so that I can share any use cases with our development team to prioritize the issue appropriately.
-Dave
#32013
- 1P_Dave
Moderator
Hello AJCxZ0! 👋
Thank you for reporting this! Our developers are aware of an issue where dates that include years higher than 3000 aren't displaying properly in the 1Password app. An internal work item is open in our backlog to investigate this further and get it fixed in a future version of 1Password.
Out of curiosity, is there a practical reason why you need to enter 3000 or higher as the year? Or was this just the result of testing the app? I'm asking so that I can share any use cases with our development team to prioritize the issue appropriately.
-Dave
#32013
Years later...
Now it appears that trying to enter a date beginning "300" gets forcefully changed to "190" when the fourth digit is added. Trying to delete digits results in the being forcefully re-inserted.
Is 1Password aware of some future cataclysmic event?
