Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[richardc]

 
Bugfix request:- Date input strings are not read according to local date format.  (no reply to post on: March 12, 2013)

This is a request to fix a non fatal, but quite annoying bug which occurs in English speaking countries 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 conforms to the US style date format: "MM-dd-yy". Consequently it reads 09-11-yyyy as September 11, when it should know that the 9th of November is intended in this context.  

The parsing algorithm has some versatility because it will change its interpretation if one of the first two digits happen to be greater than 12 - but this self adjustment 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 faulty assumptions might be built into the code libraries which programmers use to create applications like MC and MediaPlayer, although it could be that the issue is invisible to US code writers generally.)

Perhaps I am alone and there is something unique to my system (AMD processor & WinXP32), however I feel there must be many MC customers in the UK and other countries with British heritage, which employ the "dd-mm-yy" date convention, who have confronted this problem.

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 can become bearable - that is, until you want to edit a Time field on a photograph (for example).

In this 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 whenever a time field is modified. This is terribly inconvenient and needs to be fixed.
 

[6233638]

The parsing algorithm has some versatility because it will change its interpretation if one of the first two digits happen to be greater than 12 - but this self adjustment does not work for the first twelve days of every month.

I've just had a look at my library with the "Month" field listed and... you're right.

All of my music that I've tagged since using Media Center now has the date tagged incorrectly, because it was accepting dd/mm/yy values without correcting them - so I assumed that was the format it expected.

Edit: Actually no, I was looking at the wrong date field there, as I have both [Date] and [Release Date] and it just happened to match up.

I've been entering dates as dd/mm/yy and it seems to be working as intended.

[richardc]

I've been entering dates as dd/mm/yy and it seems to be working as intended.

Thanks for checking Citizen, but if you really don't have this problem then my problem must be due to some factor external to Media Centre - but... like what? I know I'm not hallucinating. The stored date information is always displayed correctly, however input strings are not read correctly if the Day is less than 13 and your local format is dd/mm/yy.

Experimental details. If your system is set up for the USA, first go to Control Panel, set "Regional and Language Options" to "English (Australia)". (Has NAFTA forced Canadians to use US date formats?)   Start up MC. All existing date info should now be displayed in dd/mm/yy format.

Next, I recommend selecting "Images" and finding a list or folder of digital photographs. The sole reason is that digital photos (from a camera rather than a scanner) are most likely to contain complete Date-Time information. Set the list-style to "Details" and check that the "Date" field is visible on screen. My MC displays date & time together in this column. You may optionally add two more columns for "Day" and "Month", like Citizen above, to avoid any possible confusion.

Find some photographs taken on a "Day" of the month from 1 to 12 (check the Day number is not the same as the Month). Next, open a Tag for for one of these photos. Scroll to the "Date" field in the Tag, which should also contains the time value. Activate the field for editing and modify the time value so that it says one minute earlier. Press Enter. Observe the main screen and the Tag. The time changes by one minute, as expected, but the unedited Day and Month numbers have now been transposed. 2 June becomes Feb 6.

[MrC]

There's a thread somewhere where Matt mentions date entry is in typical US style.  It has some heuristics to figure out the obvious cases when other formats are used.  I can't find the thread though, sorry.

[6233638]

While I can't guarantee that everything is working correctly, all the albums I have checked so far, where both the day and month are 12 or less seems to be getting displayed correctly.

What is your OS language? (mine is not set to US English)

There's a thread somewhere where Matt mentions date entry is in typical US style broken.

I fixed your post.

[richardc]

Yes 6233638, everything does display correctly. My albums usually have their date information already encoded so I rarely have to edit their dates. However, I need to invent dates and times for scanned images of negatives and slides so they will sort and display in chronological order. For such items I do need to edit the old date and time info, which, by default, is derived from the file-date. I can learn to tolerate having to remember to use MM-dd-yy as the date input format, even though dates are displayed in the local format, dd-MM-yy, but I get very frustrated having to re-enter the date in order to prevent the existing string being misread as input every time I simply want to change a time field by some small increment.  Please refer to the "experiment", above.

If this really is a unique (strange and unusual) problem which nobody else has, then I can start working on why that might be so. I am willing to explore what is unique about my system or my country settings, but nobody has reliably confirmed that this date problem with MC does not occur in other systems where the local date format is dd-MM-yy.

My OS language is English (Australian). What's yours? What's your keyboard layout? Mine is US international because we use the dollar sign "$" rather than Pounds, Euros, Kroner or DM. The following might also conceivably be relevant for the "heuristics":-

OS=WinXPsp3.
  Control_Panel/Regional_and_Language_Options/Languages/Text_services_and_input _languages/Details/Settings:
   - Default_input_language = "English (Australia) - US"
   - Installed_services = 
     1) "English (Australia) - Keyboard = US"
     2) "English (United States) - Keyboard = US"
(I seem to recall there is some difficulty with removing Microsoft's US language option completely - maybe because so many documents use US English.)

Surely, if MC can get the output format right, it can use the same information to decide how to parse input strings.
Searching the forum for "date entry" only finds this topic - no need to say "broken" or "US style".

[DoubtingThomas]

I have some C++ date code I wrote that will take a date in just about any format you can think of, and many you'd never think of, and handles AMERICAN mm/dd/yy[yy], EUROPEAN dd/mm/yy[yy] and JAPANESE yy[yy]/mm/dd based on a flag and formats it in any possible format you want (using a format string like the unix date command).   The object has getUnixSeconds()...

I'd trade it for a free upgrade to v19 ?

[Matt]

Some dates are ambiguous, like 3/4.

In these cases, the system locale and the separator (slash, dash, etc.) are considered.

If you have a particular case that seems wrong, please provide:
1) Exactly what you type
2) What it changes to
3) What you expected
4) The system short date format

Thanks.

[Matt]

Just a little bump.  Looking at the date parsing code, there's a lot there.

The ambiguous case I mentioned of 3/4 can get even a little more complex, because something like 11/12 could be:

November, 2012
December 11, [Current Year]
November 12, [Current Year]

There are a bunch of heuristics to make reasonable guesses in ambiguous cases like this.

Of course, typing something that isn't ambiguous will provide the most deterministic results.

[Twit]

Hi,

 I have tried this exactly as richardc describes and all the dates that I added a couple of minutes to remained the same. IE displayed as they should have.

I am in the UK and obviously all Windows 7 settings are set to this.

Must be some other factor affecting it.

Regards

Simon.

[Matt]

@Twit, or anyone else with a date parsing problem:

Like I said above, if you have a particular case that seems wrong, please provide:
1) Exactly what you type
2) What it changes to
3) What you expected
4) The system short date format

Thanks.

[jctcom]

System short date is set to "dd/MMM/yyyy"

When I type in "04-11-04" I expect it to be The 4th November, 2004 or "04-11-2004" instead what I get is "11/04/2004"

This only happens with dates lower than "12"  i.e. if I type in "15-11-04"  I get "15/11/2004" and it only happens if I type it with "-" instead of "/".

Any time the two first entries are below "12" it reverses them.

Also this problem has carried over into MC19

Carl.

[Matt]

System short date is set to "dd/MMM/yyyy"

What locale / country offers that choice?  I'll test the same here.

Thanks.

[MrC]

jctcom appears to be from Canada.

[jctcom]

Yep.  Up here in the very green part of the great white north.

Carl.

[adamt]

System short date is set to "dd/MMM/yyyy"

When I type in "04-11-04" I expect it to be The 4th November, 2004 or "04-11-2004" instead what I get is "11/04/2004"

This only happens with dates lower than "12"  i.e. if I type in "15-11-04"  I get "15/11/2004" and it only happens if I type it with "-" instead of "/".

Any time the two first entries are below "12" it reverses them.

Also this problem has carried over into MC19

Carl.

I can confirm this.
I've attached my language settings.

[Matt]

I know a little more about this one.

We're trying to figure out if the system prefers month/day or day/month ordering.

However, we get confused when you use a month name instead of a month number in your system short date format. 

I'll try to get this sorted next build of MC19.

Keep in mind that there are still some ambiguous cases.  For example, you've told the system you want "04-Nov-2004" but you're entering "04-11-04" in MC.  That will work, but if you also change the separators to something like "04/11/04" you'll be back to ambiguous results (we assume month/day/year when slashes are used and slash isn't the system separator).

[MrC]

Is there a reason not to be more lax on the separator but strict with the system date component order?

[Matt]

Next build:
Fixed: When the system short date format used the month as a string instead of a number, it could cause date parsing to make incorrect guesses with regards to day and month ordering for ambiguous dates like '3-4'.

[Matt]

Is there a reason not to be more lax on the separator but strict with the system date component order?

I agree.

I think anything of the form #.#.# (where dot is any separator) should parse using system ordering.

The only exception is if the first number is clearly a year (and the system ordering doesn't specify this) then it should be year.month.day.

I'll change it in a coming build.  Can I blame you if it causes trouble

[MrC]

Seems reasonable.