2 Added examples for 'given context', highlighted conclusion
source | link

Taking into account that this question was asked in the UX section of stackexchange, I would assume that the answer should focus on the user's expectations.

I have personally been working in a large Y2K project, and I would expect that software developers have learned their lesson from such projects. However, there still seems to be a certain disagreement about what that lesson is. It is not that 2-digit years are always evil.

It is a historic misconception that the primary reason for storing year values in 2 digits was to save storage memory. The truth is that the users wanted 2-digit years in their interface mainly because they did not want to enter unnecessary data. The developer'sdevelopers' fault was not to differentiate between the user interface data and the stored data. It would have been perfectly okay to use 2-digit years in the user interface, as long as they were stored in 4 digits. If done so, any ambiguity would have been detected instantly instead of years later.

As a consequence, when it comes to UX, I would answer that it is perfectly acceptable to use 2-digit years in the user interface, as long asit is perfectly acceptable to use 2-digit years in the user interface, as long as

  • it is not ambiguous in the given context
  • it is always stored as a 4-digit value

To illustrate 'given context':

  • a flight date on a booking site works well with a 2-digits year, because the user will never be able to book a flight date that is over 100 years in the future
  • a birthday date will hardly ever work well with a 2-digit-year, because at least some people get older than 100 years

Taking into account that this question was asked in the UX section of stackexchange, I would assume that the answer should focus on the user's expectations.

I have personally been working in a large Y2K project, and I would expect that software developers have learned their lesson from such projects. However, there still seems to be a certain disagreement about what that lesson is. It is not that 2-digit years are always evil.

It is a historic misconception that the primary reason for storing year values in 2 digits was to save storage memory. The truth is that the users wanted 2-digit years in their interface mainly because they did not want to enter unnecessary data. The developer's fault was not to differentiate between the user interface data and the stored data. It would have been perfectly okay to use 2-digit years in the user interface, as long as they were stored in 4 digits. If done so, any ambiguity would have been detected instantly instead of years later.

As a consequence, when it comes to UX, I would answer that it is perfectly acceptable to use 2-digit years in the user interface, as long as

  • it is not ambiguous in the given context
  • it is always stored as a 4-digit value

Taking into account that this question was asked in the UX section of stackexchange, I would assume that the answer should focus on the user's expectations.

I have personally been working in a large Y2K project, and I would expect that software developers have learned their lesson from such projects. However, there still seems to be a certain disagreement about what that lesson is. It is not that 2-digit years are always evil.

It is a historic misconception that the primary reason for storing year values in 2 digits was to save storage memory. The truth is that the users wanted 2-digit years in their interface mainly because they did not want to enter unnecessary data. The developers' fault was not to differentiate between the user interface data and the stored data. It would have been perfectly okay to use 2-digit years in the user interface, as long as they were stored in 4 digits. If done so, any ambiguity would have been detected instantly instead of years later.

As a consequence, when it comes to UX, I would answer that it is perfectly acceptable to use 2-digit years in the user interface, as long as

  • it is not ambiguous in the given context
  • it is always stored as a 4-digit value

To illustrate 'given context':

  • a flight date on a booking site works well with a 2-digits year, because the user will never be able to book a flight date that is over 100 years in the future
  • a birthday date will hardly ever work well with a 2-digit-year, because at least some people get older than 100 years
1
source | link

Taking into account that this question was asked in the UX section of stackexchange, I would assume that the answer should focus on the user's expectations.

I have personally been working in a large Y2K project, and I would expect that software developers have learned their lesson from such projects. However, there still seems to be a certain disagreement about what that lesson is. It is not that 2-digit years are always evil.

It is a historic misconception that the primary reason for storing year values in 2 digits was to save storage memory. The truth is that the users wanted 2-digit years in their interface mainly because they did not want to enter unnecessary data. The developer's fault was not to differentiate between the user interface data and the stored data. It would have been perfectly okay to use 2-digit years in the user interface, as long as they were stored in 4 digits. If done so, any ambiguity would have been detected instantly instead of years later.

As a consequence, when it comes to UX, I would answer that it is perfectly acceptable to use 2-digit years in the user interface, as long as

  • it is not ambiguous in the given context
  • it is always stored as a 4-digit value