In my application, there is a field that represents the end of the accounting year for an entity. This "date" is the same every year, so what we currently present to the user is field with a month and day. (Think about a short date with the year omitted)

Does anyone have experience or know of research/recommendations for localizing this kind of field? I got some stakeholder input suggesting that people who think in day-month-year order will think in the same order when thinking about dates without a year. For example, "the last day of June" is mentally "thirty" (pause) "six" to someone with this mental model, but "six" (pause) "thirty) to someone who operates in month-day-year culture.

Is it as simple as dropping the year from the localized format so you have the day and month in the right order?

1 Answer 1


It is easier to change the way the date is entered than to guess how the user will think about the date. For example, as a programmer I think in 'Year, Month, Day' even though US localization would anticipate 'Month, Day, Year'. Guessing the local custom is a bad solution; instead, use an unambiguous entry method.

In this case, ask for the full month name and the day. "June", "30". Selecting the month from a list of course. You should localize the month names to the proper language, but localizing the order is less important when there is no possibility for ambiguity.

The only time that you should ever use a number for a month (and introduce the very likely possibility of confusion) is a system that users are expected to become expert in, and data entry speed is more important than learning time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.