How hard can it be to get a date?
Today is 15004 in PICK internal date values. I now know that I can add 46385 to this to get the internal MUMPS date. It is probably somewhat telling that I have this number memorized.
In our application we will often be working with dates and times. When I know I’m going to work with dates, I have to warm myself up to doing so. Date-handling is something I have had the luxury of successfully delegating, with some exceptions, since about 1984. It might not be a coincidence that my youngest child was born that year. Babies can have a way of turning all else into minutia.
After many years of date “stories” such as handling the decade in Pr1me COBOL programs in the 1970′s with a constant of “7″ sitting in WORKING STORAGE, given that the system date had only 5 characters (I kid you not), then subsequently upgrading everything once we got that 6th digit for the decade in time for 1980, in some ways I feel like I’ve done my date time (or is that timedate?). I don’t hate date-handling, but it tires me out. In advance, it seems like it should be small, but in reality, getting your act together on the time and date fronts across the board in your platform can very time (and date) consuming.
I have avoided doing anything with dates that wasn’t absolutely essential for accuracy until now. All of the dates in Build 20 of our not-anywhere-close-to-ready-for-prime-time SnupNow software application are currently shown to and collected from users in ODBC format, such as 2009-01-25, although we get a nifty drop-down calendar component for free from our Zen AJAX platform, so users need not enter them that way. I recently made an exception with two read-only dates so they looked USA-pretty as mm/dd/yyyy.
My intent was to ignore all of the output and input formatting issues first, using only that which came packaged in our tool set, until we were certain we could put dates in the database accurately, retrieve them successfully, compare them accurately, and qualify queries based on dates. Until we have confidence in the accuracy of the dates when working with our AJAX framework, I didn’t want to obscure the effort by messing with formats.
Now, you might think that I set the bar pretty low with the initial date work, but when we upgraded our pre-release database server so that dates before December 31, 1967 (PICK Day 0) could be handled by our AJAX framework, allowing me to finally get my birthday into the system through a web page, we seem to have adopted an, uh, undesirable feature in another area as it relates to MV Dates. I have worked on addressing three separate date issues this week (two down, one to go), so I’m sensing this was a wise decision on my part. Dates are not just hard for me to address as even solid, long-time, quality software companies can have problems with dates.
Once you start down the path of figuring out how to handle dates in your platform and application, you can end up spending hours of time working to standardize such work. So far, both Ken and Tom have done some date work, as have I, but none of us has been up for nailing this down for reuse in the platform. [With an agile approach to software development, at what point do you stop doing date one-offs to meet the application requirements at hand?]
I guess it is no surprise that for the hub, in this hub and spokes approach to date conversions, I’m going with the MV date, the PICK date. That means we need to switch between every type of date and MV Dates, non-standard as they might be. I used to work with ANSI Julian dates, but given that those have no role to play in anything I’m doing right now, it would be silly to introduce them simply for the purpose of having a hub date format with which more people (perhaps mostly COBOL programmers) are familiar.
There really are plenty of details to consider when working with dates. At least it makes me feel young when I think to myself: how hard can this be, I just need a date!