std.date proposal

[Walter Bright]

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?

> 
> 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.

> +-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.