std.date proposal

[Fredrik Olsson]

Walter Bright skrev:
> Fredrik Olsson wrote:
>> I see your point, and will try to explain why I have chosen double as 
>> I have.
> 
> I have some more thoughts on using double <g>.
> 
>> Using double I get the same scale for dates for timestamps, as for 
>> dates; the integer part is days.
>>
>> Having dates a days with times as fractions is also how the 
>> astronomers do it, they call it Julian Days, and base it on monday, 
>> january 1, 4713 BCE as the epoch. But the idea is the same.
>>
>> It is datatype used by many database implementations (PostgreSQL, 
>> MySQL, MS SQL Server 7 (and beyond?)).
> 
> This may be a consequence of Microsoft Basic implementing time as a 
> double. Chicken or egg?
> 
For Basic I guess that can be true, why they choose it for 
OLE/COM/ActiveX compenents as general is another question? For 
PostgreSQL I guess they must have a reason. You can choose to use 64bit 
int for timestamp when compiling PostgreSQL but double is still the default.

>>
>> A double can represent infinity, -infinity, and not a number can be 
>> not a date.
> 
> std.date's d_time offers d_time_nan, which fills the role of nan for 
> times. I don't see a purpose for infinity or -infinity when dealing with 
> calendar dates or file times. There is a purpose for such when doing 
> physics math, but that is way beyond the scope of std.date.
> 
I find a good infinity to be nice to have, when calling say something 
like: isInRange(aDate, now(), infinity); A date way into the future 
would be just as good for most purposes, but clean and readable code is 
nice.

>> +-270 years is sort of an limitation :), even a simple genealogy 
>> application would hit that limit quite soon. Using a double is based 
>> on the idea that the farther away from today, the less relevant is 
>> precision.
> 
> Double can appear to represent far more precision. But the system clocks 
> give quantized time (usually in millisecond precision). Doubles cannot 
> exactly represent milliseconds, so when you convert from system time to 
> doubles and back to system time, it's very possible that you can get a 
> different system time. This will play havoc with file utilities and 
> programs like make.

This along with floating point not always supported have convinced me 
though. It is rewritten with d_timestamp as a 64bit long.

// Fredrik