Re: L-date fields

[DAsmussen@xxxxxxx]

Lloyd,

In a message dated 97-09-16 03:36:54 EDT, you write:

> On Sun, 14 Sep 1997 23:20:12 -0400 (EDT), DAsmussen@aol.com wrote:
>  
>  >Yes but when it comes to the century, you're only introducing two more
digits
>  >of possibly incorrect keying.  As was stated before, it's just as easy to
>  >type 18 or even 17 as it is to type 19 or 20 -- all valid dates.  I say
use 8
>  >digit dates for D-O-B and other like fields, and stick to six for most
>  >business transactions.  A "breakover" date of 40 or so should be
>  >sufficient...
>  
>  Then the data entry people should be more careful of what they're
>  entering. The smartest date routines won't prevent wrong date entry.
>  Even if we used pick lists, there's still nothing to prevent wrong
>  entires. 

Come now, Lloyd!  Do the users on YOUR planet also ask for what they want AND
need :-)?  I've got users on the shop floor that get infuriated when you even
MOVE a field, because they cannot READ (but know what to key into "that
spot")!  Sure the wrong dates can be entered, but adding more keystrokes only
increases the possibility for error.  If the user has been on a software
package for any length of time at all, they have developed a rhythm of data
entry on the screens that they use frequently.  Yes, they eventually change
their rhythm for the new fields -- but they'd be surly for at least a month
and I'd have to put up with the "Remember when you changed that screen?"
comments in perpetuity.  Besides, the earlier comment about an already full
sub-file record still applies.

>  Yes, the program should be as smart as possible, but that does not
>  alleviate the users from any responsibility on the d/e side. That's
>  the reason for my push to have full field dates on everything.

But you're adding two keystrokes to every date field on every entry panel.
 In a user community that is already over-worked and under-paid, you're just
asking for more animosity toward the IS department.

>  I think we're going to need a smarter windowing scheme than is
>  currently available. 
>  
>  (This is very much what Bob Cozzi said in an earlier message) For
>  instance (and I still don't like it), use a 100-year sliding window
>  based on the current date (when the user is on the display). For
>  birthdates, the system will only accept the current or previous
>  century. If today is 1997/09/15, and the user enters 091597, the
>  system will "assume" 1997; however, if the user enters 091697, the
>  computer "assumes" the previous century because the date is "after"
>  today. 

Agreed, but if the dates are that smart they would work for six digits as
well as eight.

>  For the purposes of "clean" displays, I'd still have four-digit years
>  on the screen and reports.

That's your perogative.  If YOUR users aren't going to show up at your door
with torches and a battering ram like MINE would, more power to you...

Regards,

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-Mail:  DAsmussen@AOL.COM

"Let us be thankful for the fools.  But for them the rest of us could not
succeed." --(Mark Twain)
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MAJORDOMO@midrange.com
|    and specify 'unsubscribe MIDRANGE-L' in the body of your message.
| Questions should be directed to the list owner/operator: david@midrange.com
+---