Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 + RN 4.3; site inset.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!mcvax!ukc!stc!inset!bill
From: bill@inset.UUCP (Campbell)
Newsgroups: net.internat
Subject: Re: What do we REALLY want?
Message-ID: <725@inset.UUCP>
Date: Wed, 9-Oct-85 08:12:51 EDT
Article-I.D.: inset.725
Posted: Wed Oct  9 08:12:51 1985
Date-Received: Fri, 11-Oct-85 08:36:22 EDT
References: <723@inset.UUCP>
Reply-To: bill@inset.UUCP (Bill Fraser-Campbell)
Organization: The Instruction Set Ltd., London, UK.
Lines: 34
Summary: Just one example
Xpath: stc stc-a

In article <723@inset.UUCP> jr@inset.UUCP (Jim R Oldroyd) writes:
>..... users' requirements in these days of networks and
>typesetters are already far ahead of anything that an
>enhanced character set can provide.

Here is just one example.

Almost all sites running UNIX, of any flavour, will have the
"standard" date command, plus the "standard" ctime, asctime routines in libc.
In other words, they are forced to use American date formats.

In the light of recent correspondence in net.general (USA != world), it will
come as no surprise that most citizens of the world find the inflexibility
of the date routines disappointing, or even offensive.

However, it is NOT going to be sufficient to provide fixed length translations
of the string portions of ctime output, to give, for example,

	Lun Sep 16 12:23:05 1985

There are two problems this does not address.  Firstly, one chooses a date
format to suit a particular purpose.  In some countries the layout of a 
date is required, for some legal purposes, to follow a fixed format, which is
very unlikely to be that given by ctime.  It may be that local requirements
mean the ctime output format has to be changed.  A quick survey shows that of
the 300-odd tools programs distributed with UNIX, 45 use ctime, and just over
half of those depend on the various words in the string being at *fixed*
locations.  Note that these are just the tools programs, no applications
were looked at.  There is going to be a porting problem here.

Secondly, rather a lot of people are based in areas which do not use the
24 hour GMT clock, let alone the Gregorian calendar.  Anyone got any ideas 
on what internationalisation could do (cheaply !) for them ?  Surely, in
MCMLXXXV it's not beyond the wit of man. :-)