Getting started with 1Password for your growing team, or refining your setup? Our Secured Success quickstart guide is for you.
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
4 Replies
- 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
I first noticed this while testing.
While I don't expect many legitimate use cases for items having dates before 1900 or after 2999, I would prefer there be no such arbitrary constraints. Sanity checking for data type and length to ensure that date operations work is expected, but even something as reasonable as limiting the year to four digits will upset folks who want to store dates from the Duniverse.
PS. I have not tested in other language environments, so trust that the day and month are only in the wrong order for Usonians.
- 1P_Dave
Thank you, an issue is open with our development team so that this can be fixed in the future.
-Dave
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?
