[phobos] Starting work on std.time

[Jonathan M Davis]

On Saturday 28 August 2010 07:27:36 Philippe Sigaud wrote:
> On Sat, Aug 28, 2010 at 16:21, Lars Tandle Kyllingstad
> <lars at kyllingen.net>wrote:
> > On Sat, 2010-08-28 at 03:24 -0500, Yao G. wrote:
> > > I did a quick dive on Johnathan code, and I think it's
> > > superb. I think it deserves a review, because it could be a better
> > > candidate to inclusion that mine. I'll continue porting the Boost date
> > > time library, because as I'm using it on my own code, but obviously the
> > > better one should be picked.
> > 
> > I haven't had time to really test Jonathan's code, but I've looked at it
> > and I agree it looks very good.  Which one is the better of Yao's and
> > Jonathan's, I cannot say.  They both have their strengths, and neither
> > is complete yet.
> > 
> > Perhaps we should ask for a vote on the NG?

That would probably be better once they're more complete.

> Is it too late for them to merge their code?

I haven't yet had time to look at Yao's code in detail, but I believe that he's 
more or less directly porting Boost's internal implementation of date and its 
associated classes. I specifically deviated from that, because I didn't think 
that it was the most efficient way to do it - either in terms of efficiency of space 
or efficiency of execution. Some operations are likely faster in Boost's 
implementation than mine (most notably getting the current day of the gregorian 
calendar, since it keeps the number of days as its internal state), but it has 
to convert from its internal representation of time for almost every function 
you call. Mine has the year, month, and day separately, which not only takes 
less memory, but it means that you can get those fields (likely oen of the most 
common operations) without having to do any calculations, and a number of the 
other calculations are probably more efficient because it has them separately. So, 
I think that the most common operations are going to be faster, and it takes the 
memory. I'd have to benchmark it though to see exactly what is and isn't faster. 
Also, my implementation makes it easy to add special dates like infinity without 
any of the weird stuff that Yao is being forced to do due to how Boost does it.

In any case, I don't think that there's a whole lot to merge. They specifically 
took different paths in how to implement their internals, and the APIs should be 
almost identical (since their APIs are both based on Boost's), with the 
exception of additional functionality that each of us has added. You could 
probably try and merge my TimeOfDay and DateTime (which combines Date and 
TimeOfDay) code with Yao's Date code, but I don't think that there's really any 
gain there unless it were determined that Yao's code is better.

I think that it would be of greater value for us both to continue what we're 
doing, and then compare the results. If one is clearly better, then we can go 
with that one. If one is better but is lacking in comparison to the other, then 
we can port over some of the missing functionality.

In any case, for the moment, I'm plowing along with what I've got, and while the 
APIs may be similar for the Date stuff, I expect that the time interval stuff will 
differ quite a bit more, since I'm trying to thoroughly D-ify it with ranges and 
delegates. I also combined the duration stuff for all types of time points rather 
than having separate ones for each type like Boost does, so a good chunk of it 
will likely be more generic than what Boost has. So, the overall result could be 
quite a bit different in some regards.

So, some level of merging of code may make sense later, but for now, I think 
that it would be best to just keep them separate and compare and contrast them, 
looking at the pros and cons of each, when they're more or less done.

- Jonathan M Davis