date format in forms?

[koray]

hi everyone,

in my form i have to take some date information in dd-mm-yy format.
but i don't want user to use tabs while typing. for example s/he
should simply type 280104 but 28/01/04 must appear.

what can i do for that?
should i use three input tags? but then, how can i make the cursor
jump to the next field when typing in current field is done?
or if i use one input tag, how can i keep '/' signs in the field fixed
when user types the date?

[Harlan Messinger]

"Brian" <us*****@juliet remblay.com.inv alid> wrote in message
news:10******** *****@corp.supe rnews.com...

Harlan Messinger wrote:

Brian wrote...

If it's unclear how the user's name should be represented,
shouldn't there be a single name field? Let the user type it in
as they see fit.
Forms don't split up entry of people's names just for fun. The
essential need behind split entry of the user's name is to be able
to sort alphabetically on family name.

I suppose. But a database can sort on a name, whether first + last or
last only.

Except in Iceland and some other countries, the need is to sort on family
name, so first + last is inadequate, and unknown order is worse.

I think addresses would be much easier that way, too. Where does
the postal code go? After the city (and state), like in the US,
or before it, like in France?
The requirements of most applications require the address data to
be split. I don't know about other countries, but U.S.
organizations, to get favorable postage rates, need to be able to
print mailing labels in order by ZIP (postal) code.

In that case, I might go for 2 fields: a mailing label <TEXTAREA>, and
a postal code for sorting. Of course, that raises the potential
problem that people might then not put the code in the <TEXTAREA>.

Then you're asking people to enter the same information twice. And it still
leaves state and city unavailable.

It's really hard to build a parser that knows all the rules
necessary for international commerce, but in spite of your
suggestion to the contrary I think most people can be counted on to
know which part of their address is the street, which is the city,
which is the state, and so on.
My point wasn't that users would get confused. My point was twofold:
(1) users can enter their address more easily in a textarea compared
to 6 input type=text elements. (2) it's not the users who will get
confused, it's the organization. It's hard for a commerce site to know
the proper address format for the US, France, China, Tanzania, etc.

Right, and it's a two-edged sword, because the address is needed for two
basic purposes: (1) mailing, and (2) data processing. You are correct that,
given the components of arbitrary addresses around the world, it is
challenging to put them back into the correct order for mailing. And on the
other hand, if the user enters the address in a single block, it is
challenging to break it up into the needed components.
Once they collect the city and postal code in separate inputs, how
will they know how to lay them out on their mailing labels?
I *think* that fewer problems arise if a package winds up being shipped to

55 Avenue des Paradisiers
Brussels, Brabant 1160
BELGIUM

instead of

Avenue des Paradisiers, 55
1160 Brussels
BELGIUM

than arise if the software thinks 1160 is the city and Brussels is the state
and therefore never sends the requested material at all.

from other countries, and indiscriminatel y applies locale-specific
validation rules for postal codes, phone numbers, and so forth.

Again, for telephone numbers, one should be "liberal in what you
accept": allow 0 or 1 at the beginning, allow space and formatting
characters ()-, and allow a variable amount of digits. This assumes
international visitors. For a site restricted to a country, a more
restrictive format may be appropriate.

[Brian]

Harlan Messinger wrote:

Brian wrote...

In that case, I might go for 2 fields: a mailing label
<TEXTAREA>, and a postal code for sorting.

Then you're asking people to enter the same information twice. And
it still leaves state and city unavailable.

It's trivial to look up a city/state by zip code.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Jukka K. Korpela]

Neal <ne*****@yahoo. com> wrote:

A name field is filled in by the user with their name in their
preferred form, so one field is fine.
It depends. The point that Andreas made is a good one when further
processing requires a given name and a surname (if they exist) to be
recognized. We cannot really recognize them from a name alone, without
further information.

But quite a many forms, if not most, that prompt for a name will use it
as an atomic unit only, e.g. to be printed in an envelope, and stored
into a data base for that purpose only. (If you need to identify
customers, you really need unique customer identifiers assigned by you,
instead of unique personal names.)
Dates, though, have other uses. You might want to order things
chronologically , - -

Yes, and most use of dates requires a separation of year, month, day of
month. But how you achieve that is a different thing. Maybe I'm strange,
but I find it more comfortable to type 2004-07-15 or 2004 07 15 or
whatever needs to be typed than to type 2004 followed by 07 followed by
15 in three different fields, _even if_ there's "auto-tabbing" (i.e., the
cursor automatically moves to the second field after I have typed in four
digits into the first one) and even though I know well the idea behind
that. A date is a unit of information to me. So is my name, but I find it
much more natural to use different fields for the different components of
the name.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Harlan Messinger]

"Brian" <us*****@juliet remblay.com.inv alid> wrote in message
news:10******** *****@corp.supe rnews.com...

Harlan Messinger wrote:

Brian wrote...

In that case, I might go for 2 fields: a mailing label
<TEXTAREA>, and a postal code for sorting.

Then you're asking people to enter the same information twice. And
it still leaves state and city unavailable.

It's trivial to look up a city/state by zip code.

Well, that's true--if the business has invested in a postal database and
keeps it up to date--and does the same for every country from which business
might be coming in.

[Dr John Stockton]

JRS: In article <ON************ *****@news-server.bigpond. net.au>, seen
in news:comp.infos ystems.www.authoring.html, Lachlan Hunt <lachlan.hunt @
lachy.id.au.upd ate.virus.scann ers> posted at Thu, 15 Jul 2004 07:57:34 :

koray wrote: Also, if
your interested, and would like to use the ISO 8601 format, then use
this regex.

/([0-9]{4})[-\/]?([0-9]{2})[-\/]?([0-9]{2})/
this allows
YYYY-MM-DD
YYYY/MM/DD
YYYYMMDD
(as well as incorrect versions like YYYY/MM-DD, but that doesn't really
matter, as long as it supports the correct versions)

It is easy enough, IIRC, to use a back-reference to force the second
delimiter to match the first.

what can i do for that?
should i use three input tags? but then, how can i make the cursor
jump to the next field when typing in current field is done?

Drop-downs or multiple text fields are reasonable, perhaps desirable,
for casual visitors and/or management staff. For data-entry staff
entering multiple dates routinely, ISTM best to require the order YMD,
and to allow any delimiting whatsoever; a RegExp /(\d+)\D+(\d+)\D +(\d+)/
will pick out the fields. You could also allow /(\d\d\d\d)(\d\d )(\d\d)/
or /(\d+)(\d\d)(\d\ d)/ and use whichever matches.

As may have been noted, I am not a professional typist. Yet I can enter
a date by typing 8-10 characters in about half the time I need for using
three drop-downs.

Automatic insertion of delimiters needs careful programming to allow for
backspace & pasteing.

For javascript date input and validating, see via below; note first what
the FAQ has to say on the subject.

The shortest and the fastest code are both short enough to be deployed
client-side.

P.S. If the application is not international, then it is reasonable to
stipulate the locally-preferred Y M D order, if native staff are being
used.

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> JL / RC : FAQ for news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[gmuldoon]

@julietremblay. com.invalid says...

It's trivial to look up a city/state by zip code.

Only if your app is purely US-centric.

street Address: 1 High Street
zip code: 2480
country: Australia

In Australia, this could end up as being any one of half a dozen
different addresses. Multiple nearby small towns or suburbs can share a
common "zip" code (postcode). There is definitely no uniqueness of
street names within a postcode.

Geoff M

[Brian]

gmuldoon wrote:

Brian says...

It's trivial to look up a city/state by zip code.
Only if your app is purely US-centric.

Or France-centric, or Germany-centric, or...
street Address: 1 High Street
zip code: 2480
country: Australia

In Australia, this could end up as being any one of half a dozen
different addresses. Multiple nearby small towns or suburbs can share a
common "zip" code (postcode). There is definitely no uniqueness of
street names within a postcode.

That's surprising, and good to know. So what does the postal code add
to addresses in Australia?

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[gmuldoon]

@julietremblay. com.invalid says...

1 High Street
zip code: 2480
country: Australia

In Australia, this could end up as being any one of half a dozen
different addresses. Multiple nearby small towns or suburbs can share a
common "zip" code (postcode). There is definitely no uniqueness of
street names within a postcode.

That's surprising, and good to know. So what does the postal code add
to addresses in Australia?

Nominates a preliminary postal distribution centre for subsequent
further manual sorting, where local staff will filter on the
city/town/suburb and then street fields.

In the above example 2480, the leading digit of the postcode indicates
the state (NSW/ACT=2, VIC=3, QLD=4, etc), the 480 takes it within NSW to
the Lismore distribution centre.

2480 can mean Lismore (city), Goonellabah (suburb of Lismore), Nimbin
(village 30km from city), Dorroughby (rural district), etc. Just
checked using link below - 72 different delivery areas! At least 3-4
High Streets that I know of in that set.

2481 will go to nearby Byron Bay distribution centre (for Byron Bay,
Suffolk Park, etc.)

See:
http://www1.auspost.com.au/postcodes/

Geoff M

[Pierre Goiffon]

"gmuldoon" <gm************ *@scu.edu.au> a écrit dans le message de
news:MP******** *************** *@news.asgard.n et.au

street Address: 1 High Street
zip code: 2480
country: Australia

In Australia, this could end up as being any one of half a dozen
different addresses.

In france a Zip code could also be shared by several towns, so the same
number and street name for a given zip code could possibly belong to one
town or another.

[Brian]

Pierre Goiffon wrote:

In france a Zip code could also be shared by several towns, so the same
number and street name for a given zip code could possibly belong to one
town or another.

I was about to argue with you when I remembered where you're from.
;-) But this suprised me even more than the news about Australian
codes. AIUI, each town or city gets a 2 digit code -- the first two
digits of the postal code -- and uses the last 3 digits for internal
use (e.g., divide by arrondisement). But I suppose the rural regions
are different, and share a 2 digit code among several towns?

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/