Timestamp is double.
I don't think a date dependent precision is good choice.
I vote for

/**
 Nanosecondes since 1/1/2000
 */
public typedef long d_timestamp;

This is enough for +-270 Years and has an accuracy which is good enough for me :)

Frank

John C schrieb am 2006-03-29:
>>> If you must support a common date format, it should be D/M/Y, which is
>>> used
>>> by the vast majority of countries and accepted internationally.
>>> http://en.wikipedia.org/wiki/Calendar_date
>>
>> Accepted internationally?
>
> According to the linked article. But I should have used quotation marks...

The article uses a fussy meaning for "D/M/Y" - it includes "D.M.Y", "D.M.YYYY", "D. M. Y"  and "D/M-Y" and perhaps a few more that weren't stated in the list explicitly

e.g.: Strictly speaking 01/02/03 isn't considered a date in Germany, but 01.02.03 and 01.02.2003 are.

The ones rendering the "DD/MM/YY" format totaly unusable are often the US with
"MM/DD/YY". Whenever there is a slight chance that an US entity was
involved: check for non-metric length, weight and odd dates :(

Thomas

Frank Benoit skrev:
> Timestamp is double.
> I don't think a date dependent precision is good choice.
> I vote for
> 
> /**
>  Nanosecondes since 1/1/2000
>  */
> public typedef long d_timestamp;
> 
> This is enough for +-270 Years and has an accuracy which is good enough
> for me :)
> 

I see your point, and will try to explain why I have chosen double as I have.

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

A double can represent infinity, -infinity, and not a number can be not a 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.

// Fredrik

John C skrev:
>> "M/D/Y" will stay I think, it is the US way, ambiguous or not, and there is allot of code/people out there making this assumption. If I could choose myself we would all go ISO :).
> 
> Who are these people expecting dates to appear in US format, I wonder?
> 
> A date library that has no notion of locales has no business making any region-specific assumptions and should just implement ISO8601. After all, that's what it's for.
> 
> If you must support a common date format, it should be D/M/Y, which is used by the vast majority of countries and accepted internationally. http://en.wikipedia.org/wiki/Calendar_date
> 

Ok, let me argue for my point, and they you argue why not :).

I have chosen the implementation for one single reason; I do as the SQL99 standard does. Instead of inventing my own scheme I have chosen a scheme I know, and is used by many.

I could dumb it down, and greatly reduced code size, and only allow for ISO 8601 formatting, but as I rewrote the PostgreSQL parser implementation I deliberately kept the SQL way. Because it is a known standard, and allows for some flexibility.

// Fredrik

"Fredrik Olsson" <peylow@treyst.se> wrote in message news:e0g6r2$206b$1@digitaldaemon.com...
> John C skrev:
>>> "M/D/Y" will stay I think, it is the US way, ambiguous or not, and there is allot of code/people out there making this assumption. If I could choose myself we would all go ISO :).
>>
>> Who are these people expecting dates to appear in US format, I wonder?
>>
>> A date library that has no notion of locales has no business making any region-specific assumptions and should just implement ISO8601. After all, that's what it's for.
>>
>> If you must support a common date format, it should be D/M/Y, which is used by the vast majority of countries and accepted internationally. http://en.wikipedia.org/wiki/Calendar_date
>>
>
> Ok, let me argue for my point, and they you argue why not :).
>
> I have chosen the implementation for one single reason; I do as the SQL99 standard does. Instead of inventing my own scheme I have chosen a scheme I know, and is used by many.
>
> I could dumb it down, and greatly reduced code size, and only allow for ISO 8601 formatting, but as I rewrote the PostgreSQL parser implementation I deliberately kept the SQL way. Because it is a known standard, and allows for some flexibility.

Those are fair points and I've been known to model code on other libraries myself (coming up with original APIs is hard). But it seems to me that you're copying a dubious decision made by its developers. No doubt I'm not exempt from that charge either.

>
> // Fredrik

Fredrik Olsson wrote:
> John C skrev:
>> Who are these people expecting dates to appear in US format, I wonder?
>>
>> A date library that has no notion of locales has no business making any region-specific assumptions and should just implement ISO8601. After all, that's what it's for.
>>
>> If you must support a common date format, it should be D/M/Y, which is used by the vast majority of countries and accepted internationally. http://en.wikipedia.org/wiki/Calendar_date
>>
> 
> Ok, let me argue for my point, and they you argue why not :).
> 
> I have chosen the implementation for one single reason; I do as the SQL99 standard does. Instead of inventing my own scheme I have chosen a scheme I know, and is used by many.
> 
> I could dumb it down, and greatly reduced code size, and only allow for ISO 8601 formatting, but as I rewrote the PostgreSQL parser implementation I deliberately kept the SQL way. Because it is a known standard, and allows for some flexibility.

I believe you said this earlier:

> I intend to do the bare bones, a solid foundation to build on top,
> and to be easy to do small stuff. Intervals, timezones, and more
> advanced stuff should be done with wrappers on top.

To me a good "bare bones" base would be the ISO8601 (even though I'm in the US), allowing small stuff on top, like the SQL99 stuff. I think a lot of libraries try to do to much.

Lucas Goss skrev:
> Fredrik Olsson wrote:
> 
>> John C skrev:
>>
>>> Who are these people expecting dates to appear in US format, I wonder?
>>>
>>> A date library that has no notion of locales has no business making any region-specific assumptions and should just implement ISO8601. After all, that's what it's for.
>>>
>>> If you must support a common date format, it should be D/M/Y, which is used by the vast majority of countries and accepted internationally. http://en.wikipedia.org/wiki/Calendar_date
>>>
>>
>> Ok, let me argue for my point, and they you argue why not :).
>>
>> I have chosen the implementation for one single reason; I do as the SQL99 standard does. Instead of inventing my own scheme I have chosen a scheme I know, and is used by many.
>>
>> I could dumb it down, and greatly reduced code size, and only allow for ISO 8601 formatting, but as I rewrote the PostgreSQL parser implementation I deliberately kept the SQL way. Because it is a known standard, and allows for some flexibility.
> 
> 
> I believe you said this earlier:
> 
>  > I intend to do the bare bones, a solid foundation to build on top,
>  > and to be easy to do small stuff. Intervals, timezones, and more
>  > advanced stuff should be done with wrappers on top.
> 
> To me a good "bare bones" base would be the ISO8601 (even though I'm in the US), allowing small stuff on top, like the SQL99 stuff. I think a lot of libraries try to do to much.

You have used my own words against me well.

I am thinking of rewriting date.d to only allow for properly formatted dates, times and durations according to ISO8601. And then let dateparse.d, be an entity of it's own allowing for more "complex" parsing, and formatting.

Is that a sound idea?

// Fredrik

Fredrik Olsson wrote:
> You have used my own words against me well.

lol...

> I am thinking of rewriting date.d to only allow for properly formatted dates, times and durations according to ISO8601. And then let dateparse.d, be an entity of it's own allowing for more "complex" parsing, and formatting.
> 
> Is that a sound idea?

That sounds much better to me. Any other ideas from anyone? I don't claim to be an expert in library development... but I'm trying to get better at it.

Lucas Goss wrote:
> Fredrik Olsson wrote:
> 
>> You have used my own words against me well.
> 
> 
> lol...
> 
>> I am thinking of rewriting date.d to only allow for properly formatted dates, times and durations according to ISO8601. And then let dateparse.d, be an entity of it's own allowing for more "complex" parsing, and formatting.
>>
>> Is that a sound idea?
> 
> 
> That sounds much better to me. Any other ideas from anyone? I don't claim to be an expert in library development... but I'm trying to get better at it.

If you really want a date parser that can do amazing stuff, you might want to look at the *nix 'at' command. It parses dates in a wide variety of formats. Check the sources.

It's quite anglo-oriented, but with a little imagination one should be able to widen it to other nationalities too.

Fredrik Olsson wrote:
> I see your point, and will try to explain why I have chosen double as I have.
> 
> 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?)).
> 
> A double can represent infinity, -infinity, and not a number can be not a 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 has another problem when used as a date - there are embedded processors in wide use that don't have floating point hardware. This means that double shouldn't be used in core routines that are not implicitly related to doing floating point calculations.

A time/date package should pick one representation for time, and stick with it. Other representations should be supported only by converting them back and forth to the one format.