On Thursday, June 20, 2013 17:55:37 Andrej Mitrovic wrote:
> Now that DIP37[1] is implemented (unless there are any bugs left with the implementation), is it time we split up std.datetime into its own package?

I'll get to it, but if you'll notice, bugs keep getting fixed on DIP37, so I'm not sure that jumping on it right away is a good idea. But I'll probably start on it this weekend.

> As a first step I recommend we separate out unittests into a test module:

I completely disagree with that approach. It's _much_ easier to maintain tests when they're next to the functions that they're testing (which is why testing templated types suck - you can't have the tests next to the functions unless they're tests intended for every template instantation). It's also harder to test private stuff properly if the tests aren't in the same module.

> std\datetime\core.d -- the actual implementation, name it whatever you want
> std\datetime\package.d  -- package module
> std\datetime\test.d  -- unittests

I have a fair idea of how I want to split it up and have had for some time, and it will definitely be more broken up than this. I also see no reason to do this in multiple passes as your "first step" remark implies, as if we released that way, it would require changing the code multiple times.

Don't worry. I have this under control and will have a pull request for this in the relatively near future.

- Jonathan M Davis

On 6/20/13 12:31 PM, Jonathan M Davis wrote:
> It's _much_ easier to maintain tests
> when they're next to the functions that they're testing

I agree.

Regarding breaking the module up, a possible demarcation line would be between "basic time stuff" and "calendar stuff". Basic time stuff means simple linear time without months, leap years, leap seconds, Gregorian and other calendars, and all aggravation caused by the slight mismatch between Earth's rotations and revolutions. Also basic time stuff would not worry about geopolitical stuff such as time zones, countries with different daylight savings policies and such. The "calendar stuff" module will take care of that.


Andrei

On Thursday, June 20, 2013 14:13:49 Andrei Alexandrescu wrote:
> On 6/20/13 12:31 PM, Jonathan M Davis wrote:
> > It's _much_ easier to maintain tests
> > when they're next to the functions that they're testing
> 
> I agree.
> 
> Regarding breaking the module up, a possible demarcation line would be between "basic time stuff" and "calendar stuff". Basic time stuff means simple linear time without months, leap years, leap seconds, Gregorian and other calendars, and all aggravation caused by the slight mismatch between Earth's rotations and revolutions. Also basic time stuff would not worry about geopolitical stuff such as time zones, countries with different daylight savings policies and such. The "calendar stuff" module will take care of that.

The _only_ time/date type which doesn't care about calendar stuff is TimeOfDay. It's pretty much all built around using the Proleptic Gregorian Calendar per ISO 8601. TimeOfDay represents the time of day in hours, minutes, and seconds. Date represents the date in years, months, and days without the time. DateTime holds both a Date and a TimeOfDay. None of those care about time zones or anything like that. SysTime on the other hand is for dealing with the system time, so it is an exact date and time in UTC internally, with an associated time zone which is used to convert the time whenever you ask for any of the pieces of the date or time (e.g. year or second). There really is no split between calendar stuff and non-calender stuff in std.datetime's design.

IMHO, the obvious split (and what I've wanted to do for some time) is

std/datetime/common.d
std/datetime/interval.d
std/datetime/timepoint.d
std/datetime/timezone.d

common would primarily have the free functions; interval would have the three interval types and their related range stuff; timepoint would have all four of the time point types (SysTime, DateTime, Date, and TimeOfDay); and timezone would have the time zone types.

What I'm debating at the moment is whether I should split up timepoint further (possibly putting each of the four types in their own modules), though since SysTime depends on DateTime, which depends on Date and TimeOfDay, and SysTime is by far the most used, as it's used for the system time, splitting them up won't help much if the concern is how much code is being pulled in. If you use SysTime, you're pulling in pretty much _all_ of std.datetime save for the interval stuff no matter how it gets split up.

I could also split up the time zones, but I don't know that there's much value in that, especially when they're very small as far as the API goes (though there's quite a bit of code to them internally).

But I'll start with the 4 modules as described above and then see whether I think it makes sense to split them up further after I see what that looks like.

- Jonathan M Davis

On Thursday, 20 June 2013 at 18:54:20 UTC, Jonathan M Davis wrote:
> IMHO, the obvious split (and what I've wanted to do for some time) is
>
> std/datetime/common.d
> std/datetime/interval.d
> std/datetime/timepoint.d
> std/datetime/timezone.d
>
> common would primarily have the free functions; interval would have the three
> interval types and their related range stuff; timepoint would have all four of
> the time point types (SysTime, DateTime, Date, and TimeOfDay); and timezone
> would have the time zone types.
>
If possible, I'd like to have a separate submodule for the StopWatch/Benchmarking stuff; that's probably more than 90% of what I use std.datetime for. Even if importing std.datetime.stopwatch ends up pulling most of the rest implicitly, I think the improvement to the documentation alone would be worthwhile.

Cheers,
Wyatt

On Friday, June 21, 2013 14:23:48 Wyatt wrote:
> On Thursday, 20 June 2013 at 18:54:20 UTC, Jonathan M Davis wrote:
> > IMHO, the obvious split (and what I've wanted to do for some
> > time) is
> > 
> > std/datetime/common.d
> > std/datetime/interval.d
> > std/datetime/timepoint.d
> > std/datetime/timezone.d
> > 
> > common would primarily have the free functions; interval would
> > have the three
> > interval types and their related range stuff; timepoint would
> > have all four of
> > the time point types (SysTime, DateTime, Date, and TimeOfDay);
> > and timezone
> > would have the time zone types.
> 
> If possible, I'd like to have a separate submodule for the StopWatch/Benchmarking stuff; that's probably more than 90% of what I use std.datetime for.

Eventually, it's supposed to go in std.benchmark. I'm not quite sure what I'm going to do with it right now though.

> Even if importing
> std.datetime.stopwatch ends up pulling most of the rest
> implicitly, I think the improvement to the documentation alone
> would be worthwhile.

It's doesn't use any of the rest of std.datetime. It uses core.time for TickDuration (though at this point, I'm inclined to think that TickDuration should never have existed, and we should have just used Duration), but it was created by SHOO, not me, before std.datetime was created, so its dependency on the rest of std.datetime is very low.

- Jonathan M Davis

On 6/21/13 8:23 AM, Wyatt wrote:
> On Thursday, 20 June 2013 at 18:54:20 UTC, Jonathan M Davis wrote:
>> IMHO, the obvious split (and what I've wanted to do for some time) is
>>
>> std/datetime/common.d
>> std/datetime/interval.d
>> std/datetime/timepoint.d
>> std/datetime/timezone.d
>>
>> common would primarily have the free functions; interval would have
>> the three
>> interval types and their related range stuff; timepoint would have all
>> four of
>> the time point types (SysTime, DateTime, Date, and TimeOfDay); and
>> timezone
>> would have the time zone types.
>>
> If possible, I'd like to have a separate submodule for the
> StopWatch/Benchmarking stuff; that's probably more than 90% of what I
> use std.datetime for. Even if importing std.datetime.stopwatch ends up
> pulling most of the rest implicitly, I think the improvement to the
> documentation alone would be worthwhile.
>
> Cheers,
> Wyatt

std.benchmark, where art thou...

Andrei

On Friday, 21 June 2013 at 21:35:17 UTC, Andrei Alexandrescu wrote:
>
> std.benchmark, where art thou...
>
> Andrei


Deny thy father and refuse thy name;
Or, if thou wilt not, be but sworn my love,
And I'll no longer be a std.datetime.