std.datetime is too big

[Somedude]

Le 06/11/2011 02:35, Jonathan M Davis a écrit :
> 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.
OK. I agree that a flat hierarchy is generally better than a nested one,
although 2 levels is still not too bad (provided that std is the root).
> 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.
I understand and I agree.

>>> 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
Thank you for your explanation.

Dude