This is a request to fix a non fatal, but quite annoying bug.
I live in an English speaking country where the date format is "dd-MM-yy". Media Center displays existing date information correctly according to the local system preferences. However, the input parser for date fields assumes that the input string is using the US style date: "MM-dd-yy" - it reads 09-11-2001 as September 11, when it is supposed to know that the 9th of November is what is intended. The algorithm has some versatility because it will change its interpretation (on a case by case basis) if the first two digits happen to be greater than 12 - but this does not work for the first twelve days of every month. (Similar problems with non-US date formats are annoyingly common. For example, Windows Media Player cannot produce a "Recently Added" list for the first 12 days of every month. This suggest to me that the faulty assumptions could be built into the code libraries which programmers use to create applications like MC and MediaPlayer.)
Consequences. Reentering a displayed date field such as 09-11-01 replaces the month with the date and vice versa because the assumed input format does not match the output format. The displayed value changes to 11-09-01, and pressing enter on this new text, swaps the date and month back again. When the user learns to always input dates using the US format (MM-dd-yy) regardless of the local display format, life becomes bearable - that is, until you want to edit the Time field on a photograph (for example).
To change the time record I was actually editing a combined Date-Time field, so the original displayed date was parsed as if it was a new date input along with the modified time field. It is frustrating to have to manually repair corrupted date information every time I change a time field. This is terribly inconvenient and needs to be fixed.
Author
Topic: Date input strings are not read according to output format. (Read 652 times)