View mode: basic / threaded / horizontal-split · Log in · Help
March 29, 2006
Re: std.date proposal
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
March 30, 2006
Re: std.date proposal
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
March 30, 2006
Re: std.date proposal
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
March 30, 2006
Re: std.date proposal
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
March 30, 2006
Re: std.date proposal
"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
March 30, 2006
Re: std.date proposal
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.
March 30, 2006
Re: std.date proposal
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
March 31, 2006
Re: std.date proposal
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.
April 01, 2006
Re: std.date proposal
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.
April 03, 2006
Re: std.date proposal
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.
1 2 3 4 5 6
Top | Discussion index | About this forum | D home