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!
I think your choice of using the PICK date format as your “hub” makes sense not because it is some superior format, but for the simple reason that your database is where the dates live permanently, and everything else is just a temporary abstraction.
I’m am a little confused though about your fretting over the internals of how each language stores dates. I’ve programmed in lots of different environments, and other than assembly language, whenever I asked for a date using the functions provided by that language I (almost) always have the option of getting day,month,year,hour,minute,second in some set order as a text string. And vice-versa, when I want it to store a date, I give it those values as text in a specific order.
Although I’m aware of how certain systems store dates internally as “number of seconds since whenever”, it’s something that I rarely have had to worry about. The only thing knowing that gets you is that you can’t store dates prior to whatever the starting point is. So, why shouldn’t date conversion between your different languages just be a simple matter of string manipulation instead of having to know the ins and outs of how each one stores its dates internally?
I have an anecdote that might answer the primary questions you mentioned, David. The very first thing I wanted to do with a date other than save and retrieve it was when a user selected one date from a “From” calendar, I wanted to load the the “To” calendar with a default date 30 days out (so the default for the user would be a “posting” of 30 days unless they changed that second date). It doesn’t make sense to do a round trip to the server for that. I just wanted to add 30 to something and then get that into the right format for output. I’m sure I gathered into info at the time to do that at some point in the future, but at the time I just loaded the second calendar with the same date as the one selected first for now.
You aren’t missing anything, David (other than the fact that it is not the 70’s anymore and hair is shorter these days ;-). I was just a bit peeved about all these date issues in the tools and chose to say it in this way. That said, had I not written this piece, I would not have tried to get the date 30 days into the future using mv dates. Without supporting code, I’ll just post the js function I wrote here. I’m not sure if it should stay like this, but I’m liking it right now (it works). When a user enters a PostFromDate, I show a default PostThruDate of 30 days out and also make sure that any that they enter is not before their PostFromDate.
var pickDate = odbc2pick(fromdate);
pickDate += 30;
var ODBCdate = pick2odbc(pickDate);
postthrucomp = zen(‘PostThruDate’); postthrucomp.setProperty(‘minDate’,fromdate);