On 05/01/2010 09:12 PM, Michel Fortin wrote:
On 2010-05-01 21:38:06 -0400, Andrei Alexandrescu
<[email protected]> said:
I just committed a first draft of std.gregorian. The design and the
code are copied from Jeff Garland's Boost date and time library. Once
we get the library in shape and I discuss the matter with Jeff, I'll
insert the proper attributions in the file.
http://dsource.org/projects/phobos/browser/trunk/phobos/std/gregorian.d
For the record I am stating that I have never looked at the Tango
design or implementation of dates and times or in general.
There's plenty more to do. It would be great if others could continue
this work, to which I can't dedicate much more time. Until the ongoing
issue finds a solution, only people who have not looked at Tango date
and time should work on std.gregorian.
Nice. A few comments:
1. About:
@property string toIsoString() const;
@property string toIsoExtendedString() const;
In my experience with boost, I've found these two quite useless, if not
misleading. There are so many ways to format dates in an ISO-compatible
format that nine times out of ten theses functions won't fit what you're
doing because you'll want a slightly different string, yet still
ISO-formatted. I don't remember the specifics, but I know there is a lot
of room for improvement there.
Morning! Great, that means less implementation effort :o).
2. We're still missing a way to store time values. I've made something a
while back to that end, a small module named "time" to store time values
in any the most common time units, with any precision. Perhaps it's
worth a look (it has no license yet, but consider it boost-licensed):
http://michelf.com/docs/d/mfr/time.d
Yah, my code code is just a start in hope that others will continue.
I like your time types (I assume operators can easily be revamped) but
unless we have something genuinely new to say I'd prefer us to continue
Boost's implementation, which is solid and well-documented.
If someone wants to adapt it for Phobos, I'll be glad it helped. It
needs to be switched to the new operator overloading regime, and it
misses a few unittests. And it's only a storage format: you'll want to
be able to get the current local and UTC time (although that's already
in std.date).
That said, I wonder if it might not be a little too much template-heavy
for a standard library. This gives much versatility, but do we really
gain from it? I'm not sure.
The stdlib should be a good venue for highly customizable code. That
being said, I'm not sure that goes for dates and times. Boost's date and
time allow user-defined calendars etc., feature that I did not copy. I
have asked Jeff Garland (whom I've met in person) about the benefits of
that customization.
Andrei
