Re: Scaled or Granular Dates
Date: Tue, 13 Jan 2004 05:12:29 GMT
Message-ID: <17LMb.40448$xy6.109367_at_attbi_s02>
"Christopher Browne" <cbbrowne_at_acm.org> wrote in message news:btv1jl$bjtj9$5_at_ID-125932.news.uni-berlin.de...
>
> It is therefore VERY attractive to use Julian Dates as the physical
> representation for dates.
I was speaking about the people who USE dates, not the people who write the date code. The first group outnumbers the second group by approximately 100,000 : 1. Type design, and library design, should be totally focused on the needs of the user of the component, and not at all on the implementor.
Use whatever you want for physical representation, but don't make me look at it. That's the failure of the Java date classes.
> This is hardly "fringe functionality."
It is absolutely fringe functionality for users. For implementors, it may be relevant, but if it is, they should hide the fact from the user. Almost no one cares about dates before 1752. Heck, almost no one cares about dates before 1970.
Can you name any application at all that exposes Julian calendar dates in the UI that isn't itself a Julian date calculator? Does Quicken let you enter the dates of your checks in the Julian calendar?
Marshall Received on Tue Jan 13 2004 - 06:12:29 CET