by Michael S. Kaplan, published on 2013/01/21 07:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2013/01/21/10386721.aspx
Okay, a long hiatus after surgery, I'm going to ease back into blogging. Thank you to all who have wished me well.
Those who wished me ill can take solace in the fact that they weren't completely unsuccessful. :-)
I will be talking about the injury and the hospital and the nursing home and the accessibility issues I now face as a fulltime gimp at home, at my girlfriend's place, and at work on other days, in other blogs in the future.
For today, I thought I'd cover a question from my email Inbox....
The question I was asked was:
I was using a program that was describing time durations like the ones returned by GetDurationFormat. But for longer time periods, it was describing months and years, and I couldn't get GetDurationFormat to do that. What's the secret, what am I missing?
Upon further questioning, he admitted that the program was μTorrent.
I decided not to ask what he was trying to (perhaps illegally!) download.
Or whether it was porn.
Or what porn might take weeks or months to download.
I had in mind reproing it and getting a screenshot, I explained.
He gave me the name of the file and right after I took the screenshot:
I deleted the file and uninstalled μTorrent. :-)
But it proved his point -- although I couldn't get a screenshot of it (it jumped to days too quickly and I didn't want to keep it downloading any longer than I needed to for the art. Bad enough it was on a work machine!), I did see it saying weeks for a few moments, and I could extrapolate based on the customer report to me that it was probably doing that.
I am reasonably certain that they aren't using GetDurationFormatEx or its LCID favoring cousin.
Because we never defined any other symbols to use for longer time periods.
They must be rolling their own.
Building on it by taking our function and parsing the results to extend them feels very painful and risky....
But it got me thinking about a few other things.
First of all, some people have way too much free time and free hard drive space!
Second of all, adding these might be a good idea, though it multiplies the risk of grammatical mistakes that even the current function could show with custom format strings that use words (I have seen programs that use it this way).
Third of all, the function only taking a SYSTEMTIME in lpDuration or the 100-nanosecond values in ullDuration is rather awkward. Why not the option of two SYSTEMTIME values as real datetime values to get the duration between? There are lots of usage scenarios where the function would be quite useful but either of the options we give would be quite awkward if not unreasonable. Why make them do so much extra work?
When you get down to it, a duration that is very long becomes awkward very quickly.
Like the title says, it's not how long it is, it's how you describe it when it's long!
I'll suggest something to the NLS folks (well, I'll make sure they see this blog!).
It's good to be back.
Paul Clapham on 21 Jan 2013 8:52 AM:
Good to see you back, Michael!
DaveC on 21 Jan 2013 10:47 AM:
Welcome back Michael
cheong00 on 21 Jan 2013 6:03 PM:
Welcome back!
Doug Ewell on 22 Jan 2013 7:43 AM:
Displaying time intervals generically in terms of months and years can be problematic, because months and years aren't always the same length. If the interval is 30 days, is that a "month" or not? Should it matter which calendar months were spanned by the interval? If GetDurationFormat(Ex) doesn't do this, it's probably for a reason.
Rollo on 3 Feb 2013 2:42 PM:
Agree with Doug - durations in months and years don't make any sense unless you know the starting date/time, and even then it gets rather annoying if you need to compare two durations at different starting points..
Michael S. Kaplan on 4 Feb 2013 9:53 PM:
When (or if) you're using μTorrent, then you know the exact context for weeks, months, or even years. It would be a very useful adjunct feature!