www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.gregorian

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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.


Andrei
May 01 2010
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-05-01 21:38:06 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> 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. 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://michel.com/docs/d/mfr/time.d 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. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
May 01 2010
next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-05-01 22:12:20 -0400, Michel Fortin <michel.fortin michelf.com> said:

 	http://michel.com/docs/d/mfr/time.d

Sorry, mistyped the URL. The URL you should look at is: http://michelf.com/docs/d/mfr/time.d -- Michel Fortin michel.fortin michelf.com http://michelf.com/
May 01 2010
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/01/2010 09:12 PM, Michel Fortin wrote:
 On 2010-05-01 21:38:06 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> 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
May 02 2010
prev sibling next sibling parent reply Bernard Helyer <b.helyer gmail.com> writes:
Just a quick question. Is this intended to replace or augment std.date? 
If the former, how would one go about contributing?
May 02 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/02/2010 06:55 PM, Bernard Helyer wrote:
 Just a quick question. Is this intended to replace or augment std.date?
 If the former, how would one go about contributing?

At best it should replace it, and the way to contribute is continue what I started: go down the source and the documentation of Boost.Date_Time and adapt artifacts. That is just a bit difficult because the Boost code is heavily policy-based and I think we can give up on the policies at least for the time being. (More on this later.) Andrei
May 02 2010
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 01 May 2010 21:38:06 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 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.

FWIW, I have used boost date_time in the past, but I didn't really like it. Particularly the part where every unit is its own type (dunno, that may have changed, it was several years ago that I used it). If we could try to combine these types together, I think it would be beneficial. -Steve
May 03 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Steven Schveighoffer wrote:
 FWIW, I have used boost date_time in the past, but I didn't really like 
 it.  Particularly the part where every unit is its own type (dunno, that 
 may have changed, it was several years ago that I used it).  If we could 
 try to combine these types together, I think it would be beneficial.

I haven't looked at that Boost package, but the idea behind that is if month and year have different types, bugs where a year value is mistaken for a month can be headed off at compile time. There's some modern thought that this is a good style for programming. We'll see how it pans out.
May 03 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 03 May 2010 13:46:12 -0400, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Steven Schveighoffer wrote:
 FWIW, I have used boost date_time in the past, but I didn't really like  
 it.  Particularly the part where every unit is its own type (dunno,  
 that may have changed, it was several years ago that I used it).  If we  
 could try to combine these types together, I think it would be  
 beneficial.

I haven't looked at that Boost package, but the idea behind that is if month and year have different types, bugs where a year value is mistaken for a month can be headed off at compile time. There's some modern thought that this is a good style for programming. We'll see how it pans out.

I was thinking more about how hours, minutes, seconds, etc. each have their own type. I think they do this so declaring literals is somewhat natural: // borrowing D's auto auto ts = hours(1) + minutes(20) + seconds(5); But I think these can all be global functions which return the same type, rather than returning individual types. Actually, looking at the docs again, it appears that hours, minutes, seconds, etc. are classes, but just basic classes derived from time_duration, and sole purpose of them is to construct time_duration, but it's very odd they didn't just use a function. Can anyone think of why they would have done it this way? Months and years, actually, I could understand having their own (common) type, since adding x months in terms of some standard time unit such as seconds is not trivial. This non-trivial calculation would only need to take place when adding months to a ptime. Adding months to months would be straightforward, and adding time_duration/ptime/time_period together would be straightforward. That would be a cool feature, the way we solved it in Tango is to have a function in the calendar called addMonths, but having a general "this represents a number of months" entity could be nice for things like iterating over a time period x months at a time... Actually, more bikeshedding, can we make the type names better? time_duration, time_period, ptime, ugh.... I like TimeSpan (or Span), TimePeriod, Time. -Steve
May 03 2010
prev sibling parent negerns <negerns gmail.com> writes:
On 5/2/2010 9:38 AM, Andrei Alexandrescu wrote:
 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.


 Andrei

I got the following error messages. The file test.d is just int main(string[] args) { return 0; } and gregorian.d is from the latest svn trunk. Compile: dmd test.d gregorian.d D:\projects\dmd\dmd2\windows\bin\..\..\src\druntime\import\core\sys posix\signal.d(25): Error: identifier 'siginfo_t' is not defined D:\projects\dmd\dmd2\windows\bin\..\..\src\druntime\import\core\sys posix\signal.d(25): Error: siginfo_t is used as a type D:\projects\dmd\dmd2\windows\bin\..\..\src\druntime\import\core\sys\ osix\signal.d(195): Error: identifier 'sigset_t' is not defined D:\projects\dmd\dmd2\windows\bin\..\..\src\druntime\import\core\sys\ osix\signal.d(195): Error: sigset_t is used as a type - siginfo_t is only for posix/linux; can't use it in windows. - siginfo_t isn't really used by gregorian.d but the structure tm so i included the stdc.time module instead. I modified gregorian.d and enclosed the import core.sys.posix.time within version statements. version (Windows) { import core.stdc.time; } else version (linux) { import core.sys.posix.time; }
May 16 2010