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?]
We now have a need for date manipulations in 3 languages: JavaScript, SQL, and MVBASIC, plus one: MUMPS, even if only when something is amiss. For every language and related “native format” for a date we could have conversions to and from a variety of external dates, plus a need to translate dates between every two of these “native formats.” Three is probably tops for writing routines to switch between every two of the formats. Once you get to four, and that’s where we are, it is time to switch to the hub and spokes approach. So, which date format should be our hub?
Date handling in MultiValue is pretty easy. You can subtract dates and it gets the right answer. That is one of those “you don’t know what you got ’til it’s gone” features in MV. You can handily compare dates and do date manipulations. Doing such with SQL is anything but standardized across vendors, with each database vendor having their own proprietary functions. Date handling in JavaScript is still a bit of a mystery to me, being in seconds since 1/1/1970, but obviously people have figured out how to use it and there should be enough resources out there for us. A date like 1294595536005 is too long a number to want to work with regularly, if you ask me. I can eyeball a PICK date and readily know if it is far in the future or well in the past. MUMPS (COS) dates look very like PICK dates, but if you ask a question about date-handling, someone might give you an answer like $ZDT($H,3), so I’ll not be hanging my hat there.
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!
SnupNow: Persistence Matters 
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?
As far as “date math”, since you decided on PICK as your “working” format, and since you state that it is good at handling the date math type functions. then why do need need to be concerned about doing date manipulation with things like Javascript?
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.
OK, I must have missed something. I thought the issue was dealing with different date formats when moving them between your different platforms/languages/whatever. In cases like you mention where you want to work strictly on the client side (or strictly within any of your different environments), then I don’t see the point in converting the dates to PICK format. I would just use the native Javascript date handling routines. In that case you do need to know that getTime gives it to you in milliseconds so you can add the correct constant (30 days * milliseconds in a day), but you don’t necessarily need to know the “since when” part or worry about what the number looks like.
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.
Method setPostThruMin(fromdate) [ Language = javascript ]
{
var pickDate = odbc2pick(fromdate);
pickDate += 30;
var ODBCdate = pick2odbc(pickDate);
postthrucomp = zen(‘PostThruDate’); postthrucomp.setProperty(‘minDate’,fromdate);
postthrucomp.setProperty(‘value’,ODBCdate);
}