[phobos] Status of std.gregorian

[Steve Schveighoffer]

----- Original Message ----
> From: Jonathan M Davis <jmdavisprog at gmail.com>
> To: phobos at puremagic.com
> Sent: Tue, August 17, 2010 5:42:25 AM
> Subject: Re: [phobos] Status of std.gregorian
> 
> On Sunday 15 August 2010 05:36:08 Andrei Alexandrescu wrote:
> > Thanks for  your work, Jonathan. Our decision after the issue with
> > Tango's date and  time was to use Boost's. I'd started std.gregorian as a
> > seed of a port  of Boost's date and time, in the hope that someone will
> > continue it.  Jeff Garland (Boost's date/time author) has been very
> > supportive in the  matter.
> > 
> > I very strongly suggest to stick with copying Boost's  or C++0x's date
> > and time facilities, unless we find some clearly  superior ways
> > facilitated by D's features. Developing our own date/time  library from
> > scratch risks of being at best just as capable as  Boost/C++0x but
> > guaranteed unfamiliar to everyone.
> 
> Okay. I've  started looking at boost's date/time stuff, and they do appear to 
> maintain  time internally in UTC rather than converting it to local time, which 
>
> was my  biggest fear, since I've run into a lot of problems with that sort of 
> thing  in the past. So, overall, I'd say that it looks quite good (this _is_ 
> boost  after all). I do have a few concerns, however.
> 
> 1. I'd argue that the  boost date/time libraries are way too complex for normal 
>
> usage. If you want  to do detailed date/time stuff, they look incredibly 
>flexible, 
>
> but I'd be  very worried that for the average case they're seriously overkill. 

> I'd be  worried that programmers looking for basic date/time functionality will 
>
> quickly get lost in dealing with the full boost implementation and that they 
> would do better to have a seriously simplified date/time facility without  all 
>of 
>
> the bells and whistles. That's not to say that we shouldn't implement  the 
>boost 
>
> stuff in Phobos, but I'd be concerned if it were the only  date/time facility 
> available.

I used boost::date_time a long time ago in a project where I needed timing 
facilities.  I found it to be quite unnecessarily complex, but it did work.  I 
personally like the C# time model better (same as Tango's), but clearly there is 
the desire to avoid looking at *all* like Tango's API, even if the author hasn't 
looked at it (no idea why that is).

I suggest not copying all the facilities, only the ones needed for gregorian 
calendar and dealing with time calculations.  Getting the current time is rather 
mundane boilerplate code, so copy if you wish, or rewrite from scratch, it will 
end up looking pretty much the same.

I can give you any advice you want as the developer of Tango's time modules, I 
just can't write any code.  I feel like after it is written, however, I can 
fix/improve the code that is written, since it's not Tango's base.

I would not generate the individual types for each unit (i.e. seconds, minutes, 
etc).  I would suggest representing the time in 100ns ticks as a long.  This 
gives a range of roughly 10,000 B.C. to 10,000 A.D. (with 0 being 1/1/01 A.D), 
and is the standard tick size used by Windows (and Tango, but I don't think they 
can claim ownership of this!).  Storing your time as a long makes all the math 
operations extremely easy, and should allow the compiler to inline most 
functions to simple instructions.

> 
> 2. We're looking at least 3 modules for  this - gregorian, local_time, and 
> posix_time. Ideally, they'd be something  like std.time.gregorian, 
> std.time.local_time, and std.time.posix_time, but  thus far we've avoided 
> multiple levels of modules in the std hierarchy.  Depending on the 
> implementation, having package level access between them  may be desirable (not 
>
> having ported it all, I can't say for sure), and I  think that it's fair to say 
>
> that we wouldn't want to give all of std  package-level access to the 3 of them 
>
> (though hopefully package-level access  wouldn't be required). So, it needs to 
>be 
>
> decided whether we want the three  modules to be at a deeper level than std in 

> the package hierarchy (and those  modules are likely to be _big_ even _without_ 
>
> solid unit tests - they're  split up quite a bit among source files in C++).

I never dealt with local_time.  I think one time module is enough, possibly two 
(std.time and std.gregorian).  I personally think local_time can be represented 
with UTC time with an offset, so I don't think it adds enough to warrant its own 
module.

> 3. Do you care whether  the internals are the same or if the API is absolutely 

> identical (or at  least as identical as reasonably possible when going from C++ 
>
> to D)?  Already, looking at Date, I question the choice of maintaining its 
>state 
>
> as  the number of days rather than a separate year, month, and day. I've 
> implemented a good chunk of it with year, month, day, and I think that the  
>code 
>
> is much cleaner that way. I also have to wonder why on earth they  picked 
> 1400-01-01 as the oldest date possible since that seems arbitrarily  recent, 
>and 
>
> depending on why that is, it would seem desirable to me to make  it more 
>flexible 
>
> than that. In any case, I would hope that as long as the  API and functionality 
>
> is correct that I wouldn't have to port over its  internals exactly, and I 
>would 
>
> hope that there wouldn't be a problem in  adding functionality if it seems 
> obviously valuable. And of course, some of  it may make sense if the were made 

> closer to how idiomatic D does things  (like possibly make time durations 
> ranges).

Regarding the date starting point, I think it's simply an arbitrary decision.  
It's probably more based on how far in the future it can represent than how far 
in the past.  It's probably represented with a single value to make math 
easier.  I'd suggest having both a "point in time" struct which represents an 
exact point in time (including date, down to the smallest interval possible), 
and then have a struct to represent the date and time with fields.  Then provide 
converters between the two types.  Using a single value is better when doing 
things like measuring how long between two dates, and converting to/from OS 
date/times.  For example, if I'm just storing a point in time to use as a 
reference (for maybe implementing a UI timer or something), I don't want the 
library spending time converting fields to some value it can subtract.  Using 
split values is better for specifying exact date/time in the way humans are used 
to, so it makes for a good UI tool.  It also is able to represent more dates.

Regarding a direct port, I don't feel that way, do not be concerned with 
porting/copying the API exactly.  Use D facilities wherever possible.  Use your 
own ideas when you feel they are better.  Bounce ideas off the group, I think we 
have a pretty intelligent group here, and at least two of us (SHOO and myself) 
have already implemented date/time libraries.

-Steve