× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



In article <199709160013_MC2-2096-D53A@compuserve.com>, John Carr
<74711.77@compuserve.com> writes
>
>Date:  9/15/97  5:34 PM
>
>RE:    Re: 2 digit YY on screens & 4 in DB
>
>Fred Mitchell said;
><Snip>
>>We still intend to hold all dates as the full 8 digits on the files but
>>only dates such as date of birth/retirement will request the user to
>>enter all 8 digits. Other dates will be input/displayed as six digit
>>dates and we will use windowing to determine the century before writing
>>the data back to the file.
><snip>
>>Fred Mitchell                                           
>fred@mitchf.demon.co.uk
>>Newcastle upon Tyne, England                      
>http://www.mitchf.demon.co.uk
>
>What would the program's understanding of the following be?
>(or "What did the User Intend"?)
>
>01/02/03
>02/03/01
>03/02/01
>
>In which one did I think I was entering D/M/Y 
>Which one was M/D/Y
>Which one was Y/M/D
>
>Which one would pass a TESTD opcode?   Right they all would. 
>If factor 1 was *YMD they would pass.  If it was *MDY they also would.
>If it were *DMY they still would.   
>
>What is the convention of the shop.  How is it communicated with the user?
>Do you have Literals after the input field saying 'Y/M/D Format' so the 
>users know,  is it consistent throughout your application base?
>
>Do you in one program ask for M/D/Y and in the other ask for it in Y/M/D?
>We can't help a user mis-keying 02/01 and really meaning January 2nd.
>We can however, make it clear what format we're expecting in our program.
>
>But first and foremost in this discussion of 4 or 2 position dates is the
>understanding/communication of the end user of what format is being asked.
>
>John Carr

The standard date format in the U.K. is D/M/Y and all dates in our
system must be in that format.  We validate all dates entered with our
own date routines but obviously cannot cater for the user entering a
valid, but incorrect, date.

We intend that in our payroll system all dated transactions will only
require entry of a 2 digit year as they only apply to the pay period
(week/month/etc.) currently open.  We will then convert this to a 4
digit year with a prefix of 19 if the year is greater than or equal to
70 or a prefix of 20 if the year is less than 70.

Personnel is different in that there is no such thaing as an open period
and we will require entry of a 4 digit year.

As with all upgrades to our systems, we will be on-site to install the
upgrade and educate the users.  The year 2000 changes have involved
major changes to both our systems and have been in the final testing
stages for over two months now.  We have already started the education
process for our users by running user meetings throughout the U.K and
intend carrying out the first installations early in 1998.

By the way, all of the changes required for the year 2000 are supplied
free of charge as part of our customers maintenance agreements which
also includes any bespoke work we have carried out for them. 

-- 
Fred Mitchell                                           fred@mitchf.demon.co.uk
Newcastle upon Tyne, England                      http://www.mitchf.demon.co.uk
+---
| 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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.