Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 +SENDMAIL+2.11; site dcl-cs.UUCP
Path: utzoo!linus!decvax!ucbvax!ucdavis!lll-crg!seismo!mcvax!ukc!icdoc!dcl-cs!stephen
From: stephen@dcl-cs.UUCP (Stephen J. Muir)
Newsgroups: net.internat
Subject: Re: What do we REALLY want?
Message-ID: <668@dcl-cs.UUCP>
Date: Wed, 9-Oct-85 22:38:06 EDT
Article-I.D.: dcl-cs.668
Posted: Wed Oct  9 22:38:06 1985
Date-Received: Sat, 12-Oct-85 07:29:36 EDT
References: <723@inset.UUCP> <725@inset.UUCP>
Reply-To: stephen@dcl-cs.UUCP (Stephen J. Muir)
Organization: Department of Computing at Lancaster University.
Lines: 36
Xpath: icdoc ivax

In article <725@inset.UUCP> bill@inset.UUCP (Bill Fraser-Campbell) writes:
>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.
>
>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. :-)

The answer is quite simple.  Put all the date conversion routines in the
Kernel code with system calls for user programs to fetch the date in string
form or whatever.  This way, local changes can be made to the kernel code to
accommodate variations, without having to recompile any programs.  Of course,
this kernel code would run in user mode (where possible) so as not to lock-out
other processes.

I stress that the kernel *must* still store the time internally in GMT.  This
is so that, e.g., tar tapes will have the correct time when taken to another
system.
-- 
UUCP:	...!seismo!mcvax!ukc!dcl-cs!stephen
DARPA:	stephen%lancs.comp@ucl-cs	| Post: University of Lancaster,
JANET:	stephen@uk.ac.lancs.comp	|	Department of Computing,
Phone:	+44 524 65201 Ext. 4599		|	Bailrigg, Lancaster, UK.
Project:Alvey ECLIPSE Distribution	|	LA1 4YR