March 28, 2006
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
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
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
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
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
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
> "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
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
>> 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
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 6 7 8 9
Top | Discussion index | About this forum | D home