Time On My Mind

I'm still working on the application from my last post, Pluto. It's a rendering application for reports that connects to a reporting service (Uranus) and renders the reports to disk.

Well, I'm getting further on with the parametrized input, and I want to display the dates to the user using something a bit more apt that a simple textBox. The DateTimePicker seems to fit the bill perfectly. All I have to do is check the type of the parameter, and make one if it's a date. Simple!

Again, not so simple. I try to make a DateTimePicker and pass the default value of a date-parameter to it.

Exception!

It seems the DateTimePicker doesn't understand the string it's been passed. That's strange, I think, it must be in some kind of non-obvious format then. I fire up the debugger to look at the string directly (by the way, the debugger in Visual Studio is a dream. It really is great. Great as in WOW, GREAT!). Well, the string is in the format "1/29/2007 12:00:00 AM". Well, I can read that - why not the parser?

I'm chalking this one up to not being familiar with the .NET framework, but the way it handles dates had me stumped for a long while. I am writing this from Norway, and we usually don't use the American form of dates (month/day/year). We use the eminently superior day/month/year, which at least leads itself to some sorting. Personally I prefer the sortable ISO standard, but I realize I'm probably never getting that to fly with my wife. So, I was a bit surprised to see Uranus spit that at me (the machine is just down the hall from me, I thought it'd have the same local settings as I have. Obviously, the server-room lies on a small patch of American soil or something. No matter. When I'd figured out that the problem was with the Culture I thought I'd try to fix this in an elegant manner.

The elegant way of solving this would be to ask the ReportingService (Miranda, mentioned in the last post) what date it prefers, and gracefully use that. My plan was to delegate the parsing of it to the widget the user interacts with to keep all of the format logic out of the app itself. It's simple, elegant, it scales and it's all-around wholesome. Too bad it didn't work.

I probably spent two hours today searching for SOME WAY to get the reporting service to tell me what its preferred time-format was. I can't find it! I ended up giving up completely and just forcing conversion to and from strings internally to be done using the "en-US" format. It works, but it's hard-coding a bit of functionality that I really didn't want to hard-code.

To make for an easy fix I've at least stored the dateFormat as a global variable. That way I can go back to my original plan if someone tells me how to get the blasted service to give up the goods.