std.datetime is too big

Jonathan M Davis jmdavisProg at gmx.com
Sat Nov 5 18:35:21 PDT 2011


On Sunday, November 06, 2011 00:22:19 Somedude wrote:
> Le 05/11/2011 19:33, Jonathan M Davis a écrit :
> > ...
> > - Jonathan M Davis
> 
> Thank you for your comprehensive response. It's very appreciated.
> I am also interested in knowing why splitting the module was dropped.

In general, Phobos doesn't do submodules. It's a fllat hierarchy. We've changed 
that some recently in a few cases, but it's still mostly true. When 
std.datetime was introduced, it was decided that there was no need to split it 
up. It worked just fine as a single module. Splitting it into several sub-
modules would have complicated things and went against how Phobos has 
generally been organized.

Any further discussions on splitting it up have come pretty much to the same 
conclusion with the addition that changing it now would break code, and the 
change just isn't worth it.

Beyond that though, I'd have to go digging through the archives to find what 
all of the specific reasons for not splitting it up were.

> As I said, it would make things a bit clearer, especially since the
> sources embark the unit tests.
> And a Ddoc page that spans a hundred screens long strikes me as unsound.

There would be just as much documentation if it were split up. The main 
problem IMHO is the fact that there is not a good way to navigate it (i.e. a 
proper set of links at the top that represent the hiearachy). So, instead of 
being able to easily hop to the type or function that you care about, you have 
to scroll or search for what you want. It becomes much harder to get an 
overview of the module. Proper links would go a _long_ way to fixing the 
problem. But until ddoc is improved, I can't do that. No one who has said that 
they were going to look into or work on the issue has actually gotten far 
enough to submit any fixes AFAIK.

> > Splitting of the time zones could be done, but I don't know why
> > anyone would ever use them without SysTime, so I don't see much point in
> > putting them in another module.
> 
> I agree time zones without Systime is unlikely, but is it possible to
> use Systime without time zones, say for file timestamp for example ?

SysTime has member which is a timezone. Its design requires a TimeZone. It 
maintains its time internally in UTC (hecto-nanoseconds since midnight January 
1st, 1 A.D. to be precise), and it converts that value to whatever the 
appropriate time zone is based on its timezone property. It avoids problems 
with DST that way. That's a core part of the design.

As for file timestamps, IMHO it would be very bad to have them without a 
timezone, unless they were just naked UTC. But inevitably, that leads to 
people trying to "adjust" that integral value to the local time or whatever 
time zone they want instead of leaving the time in UTC at all times (aside 
from when converting it to a string or asking for its year or whatnot). C does 
it that way, and it causes a number of problems. SysTime encapsulates it so 
that you don't have to worry about it. The time is always in UTC, and if you 
want to know the value in your local time zone, you ask it, and it uses its 
TimeZone to convert it to the appropriate value. Its internal time is never 
converted, so it avoids conversion errors.

- Jonathan M Davis


More information about the Digitalmars-d mailing list