View mode: basic / threaded / horizontal-split · Log in · Help
March 28, 2006
std.date proposal
I have created a proposal for a std.date replacement. And announce it 
here in hopes of some comments and criticism.

The parse code in converted from the PostgreSQL C code base, and is 
quite competent. If SQL99 supports it, then PostgreSQL does. Thanks goes 
to the postgres hackers.



The philosophy is that date and time can be represented with four basic 
types:

d_date - For a date with day precision.
d_time - For a time with millisecond precision (No date part).
d_timestamp - For a date+time with better than millisecond precision for
	dates close to present day.
d_duration - A fixed of relative duration of time. A months and a year,
	is relative as no two months are guarantied to have the same
	length, while weeks and hours are fixed (No support for leap
	seconds :) ).

The module is kept simple and consistent, all types are handled with 
just a few functions:

toType() - functions, with many overloads to make a time/date/duration
	from a string, different time units, Unix epoch, and more. For
	example toTime(hour, minute, second) and toDuration(string).

age() - functions with overloads to get the duration between two dates,
	times, or timestamps in fixed or relative units. For example:
	age(toDate("2006-02-01"), toDate("2006-03-01");
	will give "28 days", while:
	age(toDate("2006-02-01"), toDate("2006-03-01", true);
	Will give "1 month".

splitType() - functions with overloads, to split type into it's
	components. For example:
	int year, dayOfYear;
	splitDate(toDate("2006-10-28"), year, dayOfYear);

extract() - With overloads, extract a component of a type, or converts
	the type to special representations. Example:
	extract(toDate("2006-03-28"), DatePart.WEEKDAY);
	will give WeekDay.TUESDAY, and:
	extract(toDate("2006-03-28"), DatePart.EPOCH);
	will give 1143496800.

increment() - With overloads to add both a single date part, and
	duration to each type. For example:
	increment(toTime("01:02:03"), DatePart.HOUR, 4);
	Will give "05:02:03". And:
	increment(toDate("2006-02-12"), toDuration("3 months"));
	will give "2006-05-12".

truncate() - With overloads for each type, truncates a type to a given
	unit. For example:
	truncate(toDate("2006-08-12"), DatePart.QUARTER);
	will give "2006-06-01", and
	truncate(toDate("2006-03-28"), DatePart.WEEK);
	will give "2006-03-27".

toString() - With overloads for each type, converts to strings
	optionally with a formatting string (Not fully implemented).



A full documentation is available at:
http://peylow.no-ip.org/~peylow/date.html

The source is available at:
http://www.dsource.org/projects/dlisp/browser/branches?rev=51


Comments om implementation, documents and so forth are requested. I have 
no plans to ad any more functions as I like to keep simple things 
simple. But I do plan to add more "DatePart"'s, for example JULIANDAY 
for all the astronomers, and also extract date parts from other 
calendars, such as Arabic etc.

I have intentionaly not included conversion of weekdays and month into 
english names. As I believe that is up to the GUI, and locale parts of 
an applicition, not the low level lib.


regards
	Fredrik Olsson
March 28, 2006
Re: std.date proposal
Fredrik Olsson wrote:
> I have created a proposal for a std.date replacement. And announce it 
> here in hopes of some comments and criticism.
<snip>

Preliminary comments:

1. It's "millennuim" (singular), "millennia" (plural).  Two 'n's.  Not 
"millenia".  And why no CENTURY?

2. What is UDT?

3. I think you should leave out the "3/10/06" format because of the 
inherent ambiguity.  And in English, the third month is called March, 
not mars.

4. How does your module deal with time zones?

5. I've also written an alternative to std.date.  Please check it out:

http://pr.stewartsplace.org.uk/d/sutil/

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- 
PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
March 28, 2006
Re: std.date proposal
Stewart Gordon skrev:
> Fredrik Olsson wrote:
> 
>> I have created a proposal for a std.date replacement. And announce it 
>> here in hopes of some comments and criticism.
> 
> <snip>
> 
> Preliminary comments:
> 
> 1. It's "millennuim" (singular), "millennia" (plural).  Two 'n's.  Not 
> "millenia".  And why no CENTURY?
> 
Check, corrected. And century added wherever proper. Added Julian day 
when I was at it.

> 2. What is UDT?
> 
That would be a misspelled UTC, shamefully corrected now.

> 3. I think you should leave out the "3/10/06" format because of the 
> inherent ambiguity.  And in English, the third month is called March, 
> not mars.
> 
Spelling corrected, I bet there is more, way more...
"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 :).
Perhaps a mode flag should be added, to prefer YMD, DMY or MDY whenever 
an ambiguity exists?


> 4. How does your module deal with time zones?
> 
Pretty much as SQL99 does, that is you choose with or without time zone 
when time is created. Time zones are parsed, but currently ignored. I 
think the best option is to let the user simply choose if dates should 
be adjusted to UTC or to local when parsed.


> 5. I've also written an alternative to std.date.  Please check it out:
> 
I like it, looks neat and clean, and in no way competing I think. On the 
contrary I would like yours to grow and complement, as I see it a OOP 
Date/Time library on top of mine would be the best solution. Sort of 
like how std.stdio should work as the under layer for a more feature 
complete module on top.

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.


> http://pr.stewartsplace.org.uk/d/sutil/
> 
> Stewart.
>
March 29, 2006
Re: std.date proposal
Fredrik Olsson wrote:
<snip>
> Spelling corrected, I bet there is more, way more...

Like your use of "allot" in the next sentence.

> "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 :).

And there are probably at least as many people in the world who expect 
dates to be D/M/Y.  People's assumptions will differ even further on 
what century a two-digit year is in - do you have a policy on this?

> Perhaps a mode flag should be added, to prefer YMD, DMY or MDY whenever 
> an ambiguity exists?
<snip>

I guess so.  But it depends on how you define ambiguous or not.  For 
example, date notation in MS Access confused me the other day until I 
got my head around how #13/5/06# is interpreted as 13 March and 
#12/5/06# as 5 December.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- 
PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
March 29, 2006
Re: std.date proposal
Stewart Gordon wrote:
> I guess so.  But it depends on how you define ambiguous or not.  For
> example, date notation in MS Access confused me the other day until I
> got my head around how #13/5/06# is interpreted as 13 March and
> #12/5/06# as 5 December.
> 

If 13/5/06 is interpreted as 13 _March_ that is very confusing, indeed. <g>
March 29, 2006
Re: std.date proposal
Deewiant wrote:
> Stewart Gordon wrote:
>> I guess so.  But it depends on how you define ambiguous or not.  For
>> example, date notation in MS Access confused me the other day until I
>> got my head around how #13/5/06# is interpreted as 13 March and
>> #12/5/06# as 5 December.
> 
> If 13/5/06 is interpreted as 13 _March_ that is very confusing, indeed. <g>

Good catch!  NTS I meant 13 May.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- 
PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
March 29, 2006
Re: std.date proposal
> "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
March 29, 2006
Re: std.date proposal
John C schrieb am 2006-03-29:
>> "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.

Go ISO, go!

ISO is most likely the only format that is interpreted
correctly throughout the EU and Asia.

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

So, what date is: 01/02/03

1) in an Arab context
2) in an American context
3) in a British context
4) in an CJK context
5) in a Frensh context
6) in a German context
7) in an Israeli context

Thomas
March 29, 2006
Re: std.date proposal
>> 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...

>
> So, what date is: 01/02/03
>
> 1) in an Arab context
> 2) in an American context
> 3) in a British context
> 4) in an CJK context
> 5) in a Frensh context
> 6) in a German context
> 7) in an Israeli context

Ah, a trap. I could say for most of them it's 1 February 2003, but you can't 
rely on that being so. Really, it's for a good locale library to answer.
March 29, 2006
Re: std.date proposal + locales
John C wrote:
>>So, what date is: 01/02/03
>>
>>1) in an Arab context
>>2) in an American context
>>3) in a British context
>>4) in an CJK context
>>5) in a Frensh context
>>6) in a German context
>>7) in an Israeli context
> 
> 
> Ah, a trap. I could say for most of them it's 1 February 2003, but you can't 
> rely on that being so. Really, it's for a good locale library to answer. 


Anyone doing locale-specific formatting should take a look at what John 
created over here: http://svn.dsource.org/projects/mango/trunk/mango/locale/

... all kind of handy formatting, including a variety of Calendar types. 
Here's a snip from the docs:

---------------------

// Format with the user's current culture (eg, en-GB).
Formatter.format("General: {0} Hexadecimal: 0x{0:x4} Numeric: {0:N}", 1000);
// -> General: 1000 Hexadecimal: 0x03e8 Numeric: 1,000.00

// Format using a custom display format, substituting groups with those 
appropriate for Germany.
Formatter.format(Culture.getCulture("de-DE"), "{0:#,#}", 12345678);
// -> 12.345.678

// Format as a monetary value appropriate for Spain.
Formatter.format(Culture.getCulture("es-ES"), "{0:C}", 59.99);
// -> 59,99 €

// Format today's date as appropriate for France.
Formatter.format(Culture.getCulture("fr-FR"), "{0:D}", DateTime.today);
// -> vendredi 3 mars 2006

---------------------


If that's not sufficient for some, there's always the venerable ICU 
wrappers.

- Kris
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home