Time to split up std.datetime into a package?

Jonathan M Davis jmdavisProg at gmx.com
Thu Jun 20 11:54:10 PDT 2013


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


More information about the Digitalmars-d mailing list