Cloud Date Entry

Hi
Thanks for the link. Unfortunately I am talking about data entry not data
transfer and there is no way that ISO8601 has the slightest use for data
entry - real people just do not do that. After a somewhat hilarious TV
short in which people were stopped in the streets of Manhattan and ,when
asked ,could not answer the question "What date was the 9/11 Twin Towers
event", I must admit that I wonder what real people really do :-) Of course
it is confused here as 9/11 is the name of a large liquor store (open from
9am to 11pm) and anyway the date 9/11 is the Ninth of November.
I am not sure what the reference to "proper" is but I know that most
databases do not store UTC as the default and the Pick internal date is
without doubt the simplest solution. As it happens I have never come across
a transfer system that uses UTC or ISO8601 either although I know a lot of
Unix systems use some version of it for internal calculations. I do a fair
bit of interfacing and regardless of the source get some kludge that
separates the time and date leaving me to guess the real time as the card
may have been used in Albany WA one week and Griffith NSW the next. By the
way I am talking major companies such as Exxon and Caltex not just a little
local firm.
Peter McMurray
"GlenB" wrote in message
news:QYKqk.14030$Ep1.6152-at-bignews2.bellsouth.net.. .
> 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
>>
>
>

On Aug 19, 10:59*pm, "Peter McMurray" wrote:
> 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.

For casual users, you can go with the approach of having them select a
date from a calendar so that there are no post-entry validations --
only make the acceptable date choices available. This can be useful
even for the not-so-casual user, although not entirely acceptable for
any heads-down data entry (which I hear is not yet dead). cheers! --
dawn


> Peter McMurray
>
> "Tony Gravagno" wrote in
> messagenews: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- Hide quoted text -
>
> - Show quoted text -

On Aug 20, 4:33*am, Ross Ferris wrote:
> 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 :-)

You obviously don't know the Pick date functions very well :-)

61308 *IS* ambiguous, and if you iconv it it will come out as "4 Nov
1961".

UV>ED AWY.BP MICKEY
New record.

----: I
0001= PRINT OCONV( ICONV( 61308, "D"), "D4")
0002= RETURN
0003= END
0004=
Bottom at line 3.
----: FI
"MICKEY" filed in file "AWY.BP".
UV>BASIC AWY.BP MICKEY
Compiling: Source = 'AWY.BP/MICKEY', Object = 'AWY.BP.O/MICKEY'


Compilation Complete.
UV>RUN AWY.BP MICKEY
04 NOV 1961
UV>

For those who've never met it, if you ICONV 61308, it gets understood
as "day 308, year 61".

Cheers,
Wol

wrote in message
news:a8562a32-a0e2-4c5e-8ee6-a5c5d41ffb1d-at-k30g2000hse.googlegroups.com...
On Aug 20, 4:33 am, Ross Ferris wrote:
>> 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 :-)

>You obviously don't know the Pick date functions very well :-)

>61308 *IS* ambiguous, and if you iconv it it will come out as "4 Nov
>1961".


Thanks, but he was right. I mis-typed. I meant to say 6/12/2008 was
ambiguous because there's just no way of knowing if the intention was June
12th or December 6th.

One of the advantages of programming in Windows, esp VB, is that you can
rely on the local "settings" to correctly format the date.

On the other hand, relying on individual work stations to keep the correct
date and time might be a bit dicey. We generally use a subroutine call to
get the date and time as the "server" sees it. At least the users generally
enter the date in the same format all the time. I have a client who insists
on entering his dates as mm-dd-yy and can't understand why date ranges
(mm/dd/yy - mm/dd/yy) won't work (duh... mm-dd-yy-mm-dd-yy??)

Mark

"dawn" wrote in message
news:ca4893ba-793a-4293-b9d8-6ec7fd7456f1-at-59g2000hsb.googlegroups.com...

For casual users, you can go with the approach of having them select a
date from a calendar so that there are no post-entry validations --
only make the acceptable date choices available. This can be useful
even for the not-so-casual user, although not entirely acceptable for
any heads-down data entry (which I hear is not yet dead). cheers! --
dawn
Hi Dawn
It has been an interesting set of responses. I guess some people do not
have experience of setting data entry rythm that gets the job done quickly
and improves the operators' experience significantly. I am delighted to say
that I have had operators return to my sites after doing other jobs and tell
me how great my screens are to use.
Anyway I have taken the comments on board and written a routine that can
handle separate or single field entry. I realised that there are no more
key strokes to doing Day month year as separate fields or doing Day sep
month sep year in one field. Now my only concern is can North Americans
handle the day first :-) Mark's response seems to be yes.
I don't think that limiting the acceptable set of entries is a goer as one
would have to do the ISO way of Year, Month, Day and I am pretty sure that
nobody would like that
Peter McMurray
>

Come on Peter. We solved this "issue" long ago.

On all date input field, after the user enters the date, we validate
it with a nifty pop-up box that clearly spells things out:

You have entered the date as Friday, August 22nd, 2008.
If you wish to use this date, ctrl-alt-shift click on # 3
[5] [3] [1] [4] [2]

The neat thing is that each time this validation comes up, the number
you have to choose is different AND the choices come up in a different
sequence. This force people to carefully read the message and not
just automatically select some default like [Yes], [OK], etc.

Problem solved. No more operator errors. See what some great design
can do for you?

That one's a freebie. I usually charge for my innovative ideas, but
today I'm in a generous mood.

Have a great weekend.

--
Kevin Powick

LOL!

Oh oh, it is a joke, right? Never can tell these days.

Incidentally, if you've ever had the pleasure of using Treasurydirect.com,
they:

1- bring up a randomized keyboard to enter user name and password (ie a
misplaced key keyboard); you cannot enter the fields directly.
2- then they have you enter numbers from three random grid co-ordinates
shown, which you have to look up on a plastic card that they sent you three
years ago and you're frantically searching for before the session times out
in 3 MINUTES.
3- Also times out if you accidentally use the Brower Back.

That is sheer torture.

Chandru

"Kevin Powick" wrote in message
news:24417e0b-c607-473d-917b-13f34ce9f815-at-f63g2000hsf.googlegroups.com...
> Come on Peter. We solved this "issue" long ago.
>
> On all date input field, after the user enters the date, we validate
> it with a nifty pop-up box that clearly spells things out:
>
> You have entered the date as Friday, August 22nd, 2008.
> If you wish to use this date, ctrl-alt-shift click on # 3
> [5] [3] [1] [4] [2]
>
> The neat thing is that each time this validation comes up, the number
> you have to choose is different AND the choices come up in a different
> sequence. This force people to carefully read the message and not
> just automatically select some default like [Yes], [OK], etc.
>
> Problem solved. No more operator errors. See what some great design
> can do for you?
>
> That one's a freebie. I usually charge for my innovative ideas, but
> today I'm in a generous mood.
>
> Have a great weekend.
>
> --
> Kevin Powick

> On the other hand, relying on individual work stations to keep the correct
> date and time might be a bit dicey. We generally use a subroutine call to
> get the date and time as the "server" sees it. At least the users
> generally enter the date in the same format all the time. I have a client
> who insists on entering his dates as mm-dd-yy and can't understand why
> date ranges (mm/dd/yy - mm/dd/yy) won't work (duh... mm-dd-yy-mm-dd-yy??)
>
> Mark
Now that is a user I recognise :-) Which is why I raised this query in the
first place.
Peter McMurray

Hi Kevin
Like Chandru I am fondly hoping that this is a joke although my question is
serious.
Obviously , to me anyway, all programs will check that a date that is
entered is both a valid date such as 29 Feb 2000, and that it is valid in
the context in which it is entered. My way is to always display an error
for invalid dates and force re-entry. However I allow any format that
Mark's ICONV allows. I then take the internal Pick date value and match it
to an appropriate range, this step can also produce an error procedure.

Regardless of what way they actually enter the date I always display it as
Day Month Year as in 29 Feb 2000.

I had a good laugh at the suggestion that your suggestion will force a user
to "carefully read the message". Now you have stretched the rules of
interface way beyond their elasticity. I once thought like that and many
years ago for a really serious error such as recovering a batch update after
a system crash I clear the screen , draw a box and print an appropriate
error message followed by the words "Please Note This Error and Call
Excalibur". I do not have this happen very often however I can say that
when it does the odds of a person answering my query of "what was the
error?" with "Please Note This Error and Call Excalibur". are 10 to 1
against. Further prodding as to what preceded those magic words will
probably end up with a huffy "I don't know".

Also the thought of forcing a confirmation of every date in data entry
brings to mind the valid homicide defence raised by a CDP'er of Southern US
ancestry "He needed shootin'".

So I am left with entering a date in one field and forcing the user to tell
me when they first come on if they want US backwards or Real World forwards
dates. OR asking for it as INVOICE DATE d [ ] m [ ] year [ ] and
perhaps having a switch that displays it as INVOICE DATE m [ ] d [ ]
year [ ] with the option of clicking and selecting from a drop down list
if the user is not an operator with competent keying ability. Whichever way
I settle on they will always be able to default the year and I will always
validate the set and redisplay with Alpha month and 4 digit Year. By the
way I will not allow the Julian day, Mark can keep that one as his own,
although now I think about it why not for consistency, consider it done as
it is very simple to do

Peter McMurray

"Kevin Powick" wrote in message
news:24417e0b-c607-473d-917b-13f34ce9f815-at-f63g2000hsf.googlegroups.com...
> Come on Peter. We solved this "issue" long ago.
>
> On all date input field, after the user enters the date, we validate
> it with a nifty pop-up box that clearly spells things out:
>
> You have entered the date as Friday, August 22nd, 2008.
> If you wish to use this date, ctrl-alt-shift click on # 3
> [5] [3] [1] [4] [2]
>
> The neat thing is that each time this validation comes up, the number
> you have to choose is different AND the choices come up in a different
> sequence. This force people to carefully read the message and not
> just automatically select some default like [Yes], [OK], etc.
>
> Problem solved. No more operator errors. See what some great design
> can do for you?
>
> That one's a freebie. I usually charge for my innovative ideas, but
> today I'm in a generous mood.
>
> Have a great weekend.
>
> --
> Kevin Powick

On Aug 23, 1:11 am, "Peter McMurray" wrote:
> Hi Kevin
> Like Chandru I am fondly hoping that this is a joke

Joking? Me? :-)

> I once thought like that and many
> years ago for a really serious error such as recovering a batch update after
> a system crash I clear the screen , draw a box and print an appropriate
> error message followed by the words "Please Note This Error and Call
> Excalibur". I do not have this happen very often however I can say that
> when it does the odds of a person answering my query of "what was the
> error?" with "Please Note This Error and Call Excalibur". are 10 to 1
> against. Further prodding as to what preceded those magic words will
> probably end up with a huffy "I don't know".

I guess if you were smart enough to trap the error and display such a
message, you should have logged it as well. As many operators don't
report errors anyway, you might even want to have the application
"phone home" and alert you to the situation.

> OR asking for it as INVOICE DATE d [ ] m [ ] year [ ]

I tend to like it when there is no ambiguity and, as indicated
earlier, the above input method does not introduce any extra
keystrokes.

--
Kevin Powick