Re: How do I change the time in a job?

On 16-Apr-2012 21:47 , John Yeung wrote:

On Mon, Apr 16, 2012 at 7:29 PM, CRPence wrote:

Accepting of the idea that the static Job Date is used to represent
the [one] Day of the running job, there is surely a comparatively
smaller value in having a static Job Time to represent the [one]
Second of the running job

Smaller yes, but the cutoff is arbitrary. Someone may want to (for
whatever reason) use hours as their "job duration buckets" in which
case "job date" is insufficient. They would need a job time (and not
care about the minutes or seconds, just as someone using
calendar-day job duration buckets doesn't care about the hours or
minutes or seconds).

Yep, for the maximum of an hour. But which few people for which few applications should support from the OS be added ;-) Regardless, the obvious solution is to make one's own static hour value. No big deal. So why the apparent pining for a lack of something that effectively is summarily maligned?

I cannot stress enough that I really don't think any modifiable "job
duration bucket" is necessary (i.e. I would not have provided "job
date" if I were designing things), and in fact I think in many cases
having such a thing is actually an actively *bad* idea.

As many /legacy/ features are similarly deemed unnecessary or poor choices, especially by those who had never taken advantage of them in the past, but also by those who have found what they consider better ways to do what they need. The concept of the OS providing a static date for applications was originated long before the AS/400, which itself necessarily had carried all of the System/36 program and session dates along with the System/38 Job Date. These were all features that many programmers long took advantage of, and so probably, they did not generally share the opinion that the capability was a bad idea [at least while they were using them].

This is because I've seen what people can do when they see something
that looks like it might be the piece of information they want, but
is really not. (Programmer A sees "job date" and thinks "ah, the job
start date", but Programmer B has already modified this attribute so
that it no longer matches the real job start date, etc., etc., etc.)

I agree. There is almost nothing that the ill-informed or uneducated can avoid messing-up when they try hard enough to do just about anything. Of course that remains an issue irrespective of what is the subject goal or their chosen implementation. Failed assumptions are a bane for programming. But the same problem can exist with all kinds of things, even the very simple like library lists, naming, defaults, and formatting options, but especially with things like the LDA, GDA, PDA, SWS, et al. Good design reviews and code reviews, and sometimes even just coding conventions, can help quell some of the negative actions of the most irresponsible programmers. Ban the use of Job Date within the shop and enforce that convention, making any alternatives available as necessary, and move on.

Regards, Chuck