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