Cloud Date Entry

Hi
Is there an easy way to decide what nationality a party is? No, I am not
being racist merely trying to expand the reach of my software tools.
I love the Pick date routine as a simple ICONV and OCONV can deal with
practically any format thrown at it - although one does have to remember the
1930-2030 trick, Why did they do that?
Up until now my servers have always been set up with the date properly
established in the USER-COLDSTART, that is day-month-year. However now that
a user may be in the cloud they may well be one of our American cousins who
learn to do things backwards from an early age :-) When doing demos I have
always used 12.12 as that does not matter and will default to the current
year no matter what the server is set to. I suspect that order entry
operators will require a different set of options and getting them to click
on a separate selection for each of day month and year could invoke some
undesirable responses (idiots that use multiple linked telephone voice
selection menus should record the responses and you will know what I mean)
Expecting a user to read and follow a prompt that says something like
"dd/mm/yyyy" is in my opinion extremely optimistic. I can and do catch 12.1
entered on January 1 when they really mean 1.12 ie First of December however
I simply force them to acknowledge which year they really want and feel that
something more sophisticated is needed.
Peter McMurray

"Peter McMurray" wrote in message
news:UtIqk.29702$IK1.27667-at-news-server.bigpond.net.au...
> Hi
> Is there an easy way to decide what nationality a party is? No, I am not
> being racist merely trying to expand the reach of my software tools.
> I love the Pick date routine as a simple ICONV and OCONV can deal with
> practically any format thrown at it - although one does have to remember
> the 1930-2030 trick, Why did they do that?

Peter,

I take credit for that. It came up during my time as manager of virtual at
PS/RD. I modified the conv code to make that work. We threw darts at a
wall and 1930 won. Just kidding. We knew whatever we set it at, nobody
would like it. So we made it adjustable.

SET-DATE-WINDOW nn

There's no way to tell where they are without a GPS and it wouldn't matter
anyway, except certain times of the month (where have I heard that before?).
There's no way to tell if they are entering the date correctly vis-a-vie
international format or not.

6/13/2008

Perfectly valid and 50-50 chance of being wrong, depending on which side of
the waters you are.

If it's really that important, the ultimate fall-back position is always:

Month: xx Day: xx Year: xxxx

As I get older and since I discovered the c-word, I've filled out a lot of
medical and insurance forms. A lot. More than that. Just a little more...
yeah right about there. And I'm seeing that more and more, just here in the
States. Three separate fields.

Mark


> Up until now my servers have always been set up with the date properly
> established in the USER-COLDSTART, that is day-month-year. However now
> that a user may be in the cloud they may well be one of our American
> cousins who learn to do things backwards from an early age :-) When doing
> demos I have always used 12.12 as that does not matter and will default to
> the current year no matter what the server is set to. I suspect that
> order entry operators will require a different set of options and getting
> them to click on a separate selection for each of day month and year could
> invoke some undesirable responses (idiots that use multiple linked
> telephone voice selection menus should record the responses and you will
> know what I mean)
> Expecting a user to read and follow a prompt that says something like
> "dd/mm/yyyy" is in my opinion extremely optimistic. I can and do catch
> 12.1 entered on January 1 when they really mean 1.12 ie First of December
> however I simply force them to acknowledge which year they really want and
> feel that something more sophisticated is needed.
> Peter McMurray
>


Mark Brown, BSE Senior Software Engineer Three-Time Cancer Survivor (Cell)
484-716-6154

Hi Peter,

Not that it necessarily helps your situation (at the moment), but
within Visage we actually detect the date settings on the windows
workstation and adjust accordingly, for both input & display. The
client date editing routines are the largest we have I think, and take
care of getting dates in via every permutation we could think of - and
if all else fails, they can always access a context menu (right click)
for a popup calendar at any point.

IF (<-- should be a BIG IF) you go to the trouble/hassle of writing
your own DETAILED date editing routines, then if you REALLY want to,
it can also incorporate your own (parameter driven, 'cause I know you
like 'em) base year assumption for 1 or 2 digit year entry, so if you
want to move your base from "29" to "39" (or 43, assuming a retirement
age of 65!)

HTH

Ross Ferris
Stamina Software
Visage > Better by Design!

ISO8601. If the users don't like to input it that way then do as Mark
suggested and force 3 fields. Most of the (proper) computing world follows
UTC which includes ISO8601 for date formatting. I've actually considered
forcing YYYY-MM-DD in our own application, but I have far more worthwhile
projects to work on.

GlenB

"Peter McMurray" wrote in message
news:UtIqk.29702$IK1.27667-at-news-server.bigpond.net.au...
> Hi
> Is there an easy way to decide what nationality a party is? No, I am not
> being racist merely trying to expand the reach of my software tools.
> I love the Pick date routine as a simple ICONV and OCONV can deal with
> practically any format thrown at it - although one does have to remember
> the 1930-2030 trick, Why did they do that?
> Up until now my servers have always been set up with the date properly
> established in the USER-COLDSTART, that is day-month-year. However now
> that a user may be in the cloud they may well be one of our American
> cousins who learn to do things backwards from an early age :-) When doing
> demos I have always used 12.12 as that does not matter and will default to
> the current year no matter what the server is set to. I suspect that
> order entry operators will require a different set of options and getting
> them to click on a separate selection for each of day month and year could
> invoke some undesirable responses (idiots that use multiple linked
> telephone voice selection menus should record the responses and you will
> know what I mean)
> Expecting a user to read and follow a prompt that says something like
> "dd/mm/yyyy" is in my opinion extremely optimistic. I can and do catch
> 12.1 entered on January 1 when they really mean 1.12 ie First of December
> however I simply force them to acknowledge which year they really want and
> feel that something more sophisticated is needed.
> Peter McMurray
>

Hi Mark
The ICONV and OCONV date switches are magic.
The 1930 thing goes right back to the very beginnings of Pick so I don't
think that we can blame you for that. I got nailed by it in 1977 when I
wrote my first Payroll - would you believe that my partner had verbally
quoted 2 weeks without my knowledge and the client was disappointed when I
took 6 weeks to complete it from analysis to live delivery - anyway I
figured that an employee had to be at least 5 years old and checked
accordingly. Imagine the operators surprise when one of the senior employees
got rejected as not born yet, he had chosen to pop out in 1925 - I
immediately switched to forcing it to 4 digit year for display and validity
check where necessary such as payroll.
As for SET-DATE-WINDOW, guess what has never made it into any documentation,
not the REF account nor the current PDF. Sorry I haven't checked every one
of the 600 plus entries in the system BP account.
I know what you mean about those pesky forms I haven't managed the "C" case
but I have checked in on a full lights and music trip a few times recently.
We live well out of town so they met us half way on one trip - getting
transferred from my wife's car to an ambulance in the middle of a country
road with log trucks whizzing by certainly adds interest to the day :-)
Needless to say the two people in the ambulance were attractive young ladies
whose total weight probably equalled mine - not an easy lift.
As for the forms, why do so many nitwits force people to try and enter 20
digit numbers without spaces? Surely it can't be that difficult to
trim/replace spaces in the non MV world. Research shows that Joe Average
copes best with 4 digit groups. Of course the people that did the
research - Telstra for telephone numbers - completely ignore it and force a
customer to enter a new 20 digit code every month to pay the phone bill and
just to make it really easy they print it with an alpha and a dash embedded
both of which one is required to ignore.
Peter McMurray
"Mark Brown" wrote in message
news:coKdnc74b_GuxTbVnZ2dnUVZ_sLinZ2d-at-comcast.com. ..
> "Peter McMurray" wrote in message
> news:UtIqk.29702$IK1.27667-at-news-server.bigpond.net.au...
>> Hi
>> Is there an easy way to decide what nationality a party is? No, I am not
>> being racist merely trying to expand the reach of my software tools.
>> I love the Pick date routine as a simple ICONV and OCONV can deal with
>> practically any format thrown at it - although one does have to remember
>> the 1930-2030 trick, Why did they do that?
>
> Peter,
>
> I take credit for that. It came up during my time as manager of virtual
> at PS/RD. I modified the conv code to make that work. We threw darts at
> a wall and 1930 won. Just kidding. We knew whatever we set it at, nobody
> would like it. So we made it adjustable.
>
> SET-DATE-WINDOW nn
>
> There's no way to tell where they are without a GPS and it wouldn't matter
> anyway, except certain times of the month (where have I heard that
> before?). There's no way to tell if they are entering the date correctly
> vis-a-vie international format or not.
>
> 6/13/2008
>
> Perfectly valid and 50-50 chance of being wrong, depending on which side
> of the waters you are.
>
> If it's really that important, the ultimate fall-back position is always:
>
> Month: xx Day: xx Year: xxxx
>
> As I get older and since I discovered the c-word, I've filled out a lot of
> medical and insurance forms. A lot. More than that. Just a little
> more... yeah right about there. And I'm seeing that more and more, just
> here in the States. Three separate fields.
>
> Mark
>
>
>> Up until now my servers have always been set up with the date properly
>> established in the USER-COLDSTART, that is day-month-year. However now
>> that a user may be in the cloud they may well be one of our American
>> cousins who learn to do things backwards from an early age :-) When
>> doing demos I have always used 12.12 as that does not matter and will
>> default to the current year no matter what the server is set to. I
>> suspect that order entry operators will require a different set of
>> options and getting them to click on a separate selection for each of day
>> month and year could invoke some undesirable responses (idiots that use
>> multiple linked telephone voice selection menus should record the
>> responses and you will know what I mean)
>> Expecting a user to read and follow a prompt that says something like
>> "dd/mm/yyyy" is in my opinion extremely optimistic. I can and do catch
>> 12.1 entered on January 1 when they really mean 1.12 ie First of December
>> however I simply force them to acknowledge which year they really want
>> and feel that something more sophisticated is needed.
>> Peter McMurray
>>
>
>
> Mark Brown, BSE Senior Software Engineer Three-Time Cancer Survivor (Cell)
> 484-716-6154

Hi Ross
My edit routine is really simple at the moment thanks to MARK's efforts
A.IN = ICONV(A.IN,"D");* Date European
IF A.IN = NOVAL THEN
A.ERR = A.ERROR(5)
END
I wrote one based on the Hewlett Packard 25 calculator routine for the
Micromax which worked well. Unfortunately I have long since lost the code
so I whipped one up with the intention of switching it into another language
and with about 30 lines of comments and array definitions it came out in 90
lines with no multi statement lines, so I don't anticipate a major issue. Of
course people are going to have to follow a format of day and month or month
and day with any separator that they fancy and if they don't put in the year
they will get this year. A couple of extra lines can cover the Alpha month
if it is selected from a dropdown or somebody decides to type it - I can see
a data entry operator doing that when Hell freezes over.
My issue is that one can check Windows as you say ( although I have not the
slightest idea how at the moment) however what does one do if somebody
decides to use a #!@##x variant such as Ubuntu or Eve's wickedness the
Apple.
I can always split the fields as Mark says but I think that can only work
satisfactorily with stuff like medical forms, not genuine data entry. Maybe
I can force them to indicate a preference at logon but that does jump into
the stateful/stateless argument that I am trying to avoid.
Peter McMurray

"Ross Ferris" wrote in message
news:cb95ef14-c6c9-4358-a7c8-06433c6ab758-at-o40g2000prn.googlegroups.com...
> Hi Peter,
>
> Not that it necessarily helps your situation (at the moment), but
> within Visage we actually detect the date settings on the windows
> workstation and adjust accordingly, for both input & display. The
> client date editing routines are the largest we have I think, and take
> care of getting dates in via every permutation we could think of - and
> if all else fails, they can always access a context menu (right click)
> for a popup calendar at any point.
>
> IF (<-- should be a BIG IF) you go to the trouble/hassle of writing
> your own DETAILED date editing routines, then if you REALLY want to,
> it can also incorporate your own (parameter driven, 'cause I know you
> like 'em) base year assumption for 1 or 2 digit year entry, so if you
> want to move your base from "29" to "39" (or 43, assuming a retirement
> age of 65!)
>
> HTH
>
> Ross Ferris
> Stamina Software
> Visage > Better by Design!

"Peter McMurray" wrote:


>Up until now my servers have always been set up with the date properly
>established in the USER-COLDSTART, that is day-month-year. However now that
>a user may be in the cloud they may well be one of our American cousins who
>learn to do things backwards from an early age :-)

set-date-std and set-date-eur both have the L option for setting the
date format local to a given user.

If you have a thick client you get the date settings from Windows.

For browser clients, establish user preferences and read the setting
on every exchange or as-required.

For telnet, get user preferences and save them in the users file or
some other config area that's initialized on login.

While these sorts of questions are popular because they intend to
accomplish wonders without the user having to provide any information,
the reality is that this isn't the way the world works. When you
create a login on a website forum or in many other wide-area network
apps, you get to set your location and preferred time/date formats in
a Profile. A cloud-based MV application should be no different. It
will take a lot of code to try to make intelligent guesses about the
user's preferences, and very little to simply ask them once and then
everyone can forget about it.

HTH
T

On Aug 20, 12:43*pm, "Peter McMurray" wrote:
: Hi Ross
: My edit routine is really simple at the moment thanks to MARK's
efforts
: * *A.IN = ICONV(A.IN,"D");* Date European
: * *IF A.IN = NOVAL THEN
: * * * A.ERR = A.ERROR(5)
: * *END

Yeah,

But THAT would be cheating. I did say client side editing, so I
wouldn't bother taking a round-trip "hit" from a thick OR thin client.
As to your Apple & Ubuntu clients, we can detect the date settings
there as well, though as TonyG suggests, a flag on a user record makes
sense as well (which we use to determine preferred language display)

Also appreciated the (L option for set-date .... saw the release docs
that said that this COULD be set per port, but never read how/where

On Aug 20, 9:32*am, "Mark Brown" wrote:
: There's no way to tell if they are entering the date correctly vis-a-
vie
: international format or not.
:
: 6/13/2008
:
: Perfectly valid and 50-50 chance of being wrong, depending on which
side of
: the waters you are.
:

C'mon Mark, this should be 100% every time --> a seperated field
with a "13" not in the last column, which is OBVIOUSLY a day ....
even 61308 should be able to be resolved correctly every time .... now
"6138", THAT is a data that could be 50/50 :-)

Hi Tony
Thanks for that. I had a quick look at the D3 docs and guess what, they say
that SET-DATE-EUR is not supported in Windows. Incorrect as we know but it
does make one doubt the wisdom of using the L option.
Anyway you have basically confirmed my thoughts, that is that I should
simply store the user preference somewhere on the server if I am going to
get them to do data entry. I don't want to run into trouble with cookie
hater issues on the workstation. I suppose that casual users will never be
asked to enter dates so I will have to think that one through.
Peter McMurray

"Tony Gravagno" wrote in
message news:n01na45clc1vmvtlvb8gteo369ihqfdcsk-at-4ax.com...
> "Peter McMurray" wrote:
>
>
>>Up until now my servers have always been set up with the date properly
>>established in the USER-COLDSTART, that is day-month-year. However now
>>that
>>a user may be in the cloud they may well be one of our American cousins
>>who
>>learn to do things backwards from an early age :-)
>
> set-date-std and set-date-eur both have the L option for setting the
> date format local to a given user.
>
> If you have a thick client you get the date settings from Windows.
>
> For browser clients, establish user preferences and read the setting
> on every exchange or as-required.
>
> For telnet, get user preferences and save them in the users file or
> some other config area that's initialized on login.
>
> While these sorts of questions are popular because they intend to
> accomplish wonders without the user having to provide any information,
> the reality is that this isn't the way the world works. When you
> create a login on a website forum or in many other wide-area network
> apps, you get to set your location and preferred time/date formats in
> a Profile. A cloud-based MV application should be no different. It
> will take a lot of code to try to make intelligent guesses about the
> user's preferences, and very little to simply ask them once and then
> everyone can forget about it.
>
> HTH
> T
>