On Mon, Apr 16, 2012 at 3:25 AM, Vern Hamberg <vhamberg@xxxxxxxxxxx> wrote:
Hi John
I'm still curious - how would you use this "job time"? First, do you
want it to be the time at which the job started? To me, that is not as
interesting or useful as the date on which the job started.
Very reasonable questions. Honestly, when I hear the term "job date",
what goes through my mind is "date the job started". To me, it
doesn't make a lot of sense to be able to futz with this value. At
least, in anything that I would personally write, I would *either*
want the actual start date of the job, *or* the current system date.
If my logic needs to handle the case where the execution of the job
spans multiple calendar days, then I should compare the actual start
date with the current system date and handle the situation
appropriately. I have absolutely no interest in some fabricated date.
Thus, for my purposes, the concept of "job date" should not be
distinct from "start date", and "start date" should absolutely not be
modifiable.
Thus, for my purposes, the concept of "job time" would simply be
derived from, or a component of, the "job timestamp", which would be
the actual date and time at which the job started.
And yet there is this modifiable job date attribute, which clearly
*is* distinct from the actual job start date. So I have to imagine
how reasonable this is. And my conclusion is, however reasonable it
is to have a futzable job date, it is equally reasonable to have a
futzable job time. (Both of these would be components of the futzable
"job timestamp".)
So to get the "real" thing, we really want true date/time
fields. And if you want the combined value, you have
the timestamp, which is different from, say, Excel's
implementation - something you referred to earlier,
with its time as the fraction of the day.
Well, conceptually, I think of IBM's timestamp and Excel's numeric
datetime as basically equivalent. I have a problem with certain
*quirks* of Excel's implementation (namely, they chose too late a
starting point and they perpetuated a leap year error from Lotus
1-2-3), but the idea of storing a timestamp as a float, representing
the number of days (including fractions) from a starting point, is
perfectly fine to me.
John
midrange.com
