🚀 go-pugleaf

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

How about two routines, a ctime which returns american date format and a
locctime which returns local date format, or some such?  And also a routine
adatetolocdate (ugh) which converts a given date to local date format, what
ever that may be?  Then any software can use ctime to pick out bits of the
date by fixed location, still remaining portable, but date(1) and anything
else can use locctime.  Furthermore old software which was unfriendly (ie
uses only american date format) would still work, and probably be easily
patched, perhaps with adatetolocdate.  In fact, programs like readnews could
convert to local date with this, even though the news article only contains
american-style date.

I might be missing something important, not being very familiar with this
kind of stuff, but it seems like a good idea which would not cause transition
problems.

Alan J Rosenthal					decvax!utzoo!utcs!flaps
--
Note: I am not employed by University of Toronto Computer Science Department
      or Computer Services, or anything else that would come to mind.