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