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
