[Caution: techie alert!]
On 10/06/16 21:29, Peter Duncanson [BrE] wrote:
<snip>
> The use of abbreviated dates was orginally totally justified by the cost
> of internal memory and the cost and slowness of storage on tape and
> early discs.
I disagree. In fact, the /full/ date could have been stored in
two-thirds of the storage it took to hold a partial date.
It takes six bytes to store "100616" (today's date in DDMMYY format).
The trick is to use the right storage format.
When you capture a date from the user, you ask them for DDMMYYYY (in
whatever order seems fitting for your geographical area). Then you
perform the following calculation (in whatever language floats your boat):
long tojul(int yp, int mp, int dp)
{
long a=(14-mp)/12,y=yp+4800-a,m=mp+12*a-3,
jdn=dp+(153*m+2)/5+365*y+y/4-y/100+y/400-32045;
return jdn;
}
For today's date, that gives you a result of 2457550, which is easily
representable in 32 bits (four octets rather than six). And /that/ is
what you should store in the database, saving *thousands* of <insert
local currency unit here>.
This is an astoundingly convenient form in which to store dates. Want to
know how many days apart two dates are? No fussing with leap years and
30- and 31-day months. Just do: diff = LaterDate - EarlierDate and
you're done.
Want to know what day of the week a date falls on? Easy. Divide by
seven, ignore the result, and look at the remainder. 0 is Monday, 1 is
Tuesday, etc.
Want the date 100 days after this date? Easy, just add 100.
If you want to know, say, the third Thursday of the month, it's slightly
less obvious but still a darn sight easier than manipulating textual
date representations.
This is /so/ much more convenient for computation, and as a bonus it
takes two bytes less to store.
The only time you need to turn it back again is when you're writing
output (either to the screen or to a file), at which point you just do this:
void fromjul(int *yp, int *mp, int *dp, long jdn)
{
long y=4716,j=1401,m=2,n=12,r=4,p=1461,v=3,u=5,s=153,
w=2,b=274277,c=-38,f=jdn+j+(((4*jdn+b)/146097)*3)/4+c,
e=r*f+v,g=(e%p)/r,h=u*g+w;
*dp=(h%s)/u+1;
*mp=((h/s+m)%n)+1;
*yp=e/p-y+(n+m-*mp)/n;
}
and of course at this point you can show them the full four-digit year
if you wish.
(I should stress that I don't normally write C that densely!)
So this whole thing about saving storage is just not true. If they'd
really wanted to save storage in the 1950s, they'd have used Julian
dates from the very outset.
One might object that it's obvious with hindsight, but that at the time
they hadn't yet developed this algorithm... except that they /had/ - the
Smithsonian was using Julian Dates in 1957, and the International
Astronomical Union was using them in 1955.
> Everything was abbreviated if it could be.
But not enough. :-)