by Michael S. Kaplan, published on 2013/03/26 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2013/03/26/10405272.aspx
It all started with an innocent question. the innocent questioner asked:
Can you point me to any enhancements we are building for Datetime
parsing (string + datetime format to a Datetime structure) for Modern
C++ apps in the next version of Windows?
thanks
Our questioner came armed with a dangerous thing: knowledge.
Knowledge of the rich history of datetime parsing and formatting in .NET, which was required to do this support on spec, as the heir apparent to COM/OLEAUT32 in the hearts and minds of developers.
And of an even richer history of datetime parsing and formatting in COM/OLEAUT32, the first brave knight to extend Win32 where even Win32 would not dare to go.
The Windows developers knew it was
The wrong thing to do™.
But did those Developer Division developers listen?
Yeah right.
There was a long history of each group preaching sermons that the other one would ignore.
It's an ironic and unfortunate fact that there is a specific subset of the population that really dislikes being told YOU'RE DOING IT WRONG™!
It is of course the people who are, in fact, doing it wrong!
The questioner's innocent question went down a few blind alleys, with people asking about the customer scenario requirements, etc.
Then, I lost patience with the blind alleys and answered the original question directly:
To answer the original question:
Can you point me to any enhancements we are building for Datetime
parsing (string + datetime format to a Datetime structure) for Modern
C++ apps in the next version of Windows?
AFAIK, there are no specific improvements from Windows 8.
Michael
This answered the original question and bombed the village of the innocent questioner's hopes.
But there was one more message to impart, which my colleague Eric readily strafed the survivors and bayoneted the wounded:
We do not support date or time parsing on purpose. Almost invariably, the legitimate scenarios around this
should be handled by date or time picker controls. The illegitimate scenarios abound and by not providing
this, we can better direct people to use a standard format that can then be unambiguously parsed.
It seems to me that if you have to convert the format using a regex, you already know the identities of the
components and you might as well just handle the rest of the parsing (I’m not sure that time_get will add
enough value for you. It does have limitations in the scope of the dates that it can parse (I think the upper
limit is 2030 right now, though they have a bug to extend that out).
I don't know about you.
But buried in those two paragraphs is easily the most polite
YOU'RE DOING IT WRONG™!
that I have ever had the pleasure of reading in my email inbox! :-)
Joshua on 29 Mar 2013 8:14 AM:
The point of date parsing is to read user-entered dates. We are naïve if we can conclude these always come from something presenting the date picker control.
Matthew Slyman on 15 Apr 2013 3:42 AM:
Hah! I love this post! It's so true.
I developed a SQL database for one client (with non-technical but mostly reasonably smart end-users) where I insisted, for reasons of non-ambiguity, that we must use the date format "YYYY-MM-DD" throughout the entire application front-end. (Curse you Americans for muddying the waters with "MM-DD-YYYY", and for making that the default date-parsing method in many old versions of MS Office programs! I can't even count how many SQL databases and spreadsheets I've found over the years with serious data discrepancies arising from faulty/ambiguous/inconsistent parsing of dates!!! WORST of all, I remember several such cases where MS Access or Excel would silently convert all CSV-imported dates as per "MM-DD-YYYY", wherever Gregorian calendar dates could be interpreted in that way, but otherwise, would follow "DD-MM-YYYY" within the same data-set!!!) AAAAARRRRRRRRGGGGGGGGGGGHHHHHHHHHHHH!!!!! Michael, will you give the "innocent questioner" a big slap in the face please from Europe (or, from everywhere in the world except North America); unless of course they implicitly meant that Access/Excel should either be internally consistent or otherwise throw errors and warnings for cases like these?
Matthew Slyman on 15 Apr 2013 5:43 AM:
p.s. Said SQL database customer got fed up with YYYY-MM-DD (due to repeated errors by data-entry staff who weren't used to the canonical SQL date format); and eventually insisted on switching to DD-MM-YYYY. So instead of hard-coding this format into my application, I wrote a module that read Windows date-format preferences via the API, and then applied that throughout Access/VBA. I wasn't going to get caught out if this company employed some American-educated folk at some point in the future...
AMERICANS: Please note, there are other places in the world!
Matthew Slyman on 15 Apr 2013 7:19 AM:
@Joshua: "User-entered dates" in what?
i.e., What might the user enter dates into???
I've thought about this question a fair bit myself (in fact, I've built a date-parsing system that was reasonably successful at reading plain English text and detecting/identifying dates and times). I reckon that the best example cases for a requirement for date-parsing are where one must interface with legacy systems like email that can't easily be changed for everyone; or, where one must interface with non-technically-minded human beings who sometimes do silly things that can't be trained out of them, like, typing appointment information in English into the plain-text description-field of an appointment before specifying the same information in action date and time fields.
The very best example application I can think of is email... Imagine receiving an email from someone suggesting a meeting (without attaching an actual MS Office meeting request or anything similar) where the email client automatically detects (using an array of regular expressions etc.) the date and time (if applicable) of the proposed appointment (taking into account factors such as when the email was sent, which time-zone it was sent from, and where the proposed meeting is likely to be so which time zone the appointment is in). Even just going by the second half of this last sentence (before counting daylight savings transitions, non-Gregorian calendars, multi-cultural/multi-lingual societies, Mars-24 time, the communication habits of individual contacts and all that jazz), you should at least BEGIN to understand some of the potential foibles with this sort of application!
Even if you cannot understand the complexity of the above, I hope you can at least acknowledge that any practical, broadly applicable plain-language date-parsing system is going to take a lot more processing power (ergo, make a much bigger hit on mobile device battery life) than the equivalent user-interface offering a simple unambiguous date-picker.
Mr. Kaplan's point is that date/time based applications that don't have a date-picker control are DOING IT WRONG! If you want me to support you against him and his mates, you'll have to come up with better applications than I can think of... Until then, I'll concur with his opinion that date-parsing belongs in applications like Nuance OmniPage, rather than in Windows itself; because the methods of date-parsing you will favor (and the patterns you prioritize) are fundamentally connected with your application or even with the specific data set you are working on at the moment.