Proposal for custom time string formatting in std.datetime

[Walter Bright]

On 12/22/2011 1:04 AM, Jonathan M Davis wrote:
> On Thursday, December 22, 2011 00:54:49 Walter Bright wrote:
>> The most important thing is to design the boxes around the various units of
>> functionality such that there are minimal lines between those boxes. For
>> example, if I want to see if one file is newer than another (like for a make
>> program), it should not pull in timezone processing or date formatting
>> code.
>
> Both of those are part of SysTime, and the time zone in particular is an
> integral part of that. You can't do _anything_ with a SysTime without a time
> zone. That's part of the point of the design. It avoids time conversion
> issues. Sure, if stuff was rearranged, only TimeZone and LocalTime would have
> to be pulled in (since LocalTime is the default and TimeZone is its base
> class), but they have to be there regardless.

Timezone information is not necessary to measure elapsed time or relative time, 
for example.


> So, in principle, reducing how much has to be pulled in is very much
> desirable, but in this case, it doesn't make sense. The time zone stuff is
> required, and there's a usability issue if you split out the date formatting.
> It's already built into the type.

Can it be added with PIMPL? PIMPL is good for more than just information hiding, 
it can also be a fine way to avoid pulling in things unless they are actually 
dynamically used (as opposed to pulling them in if they are statically referenced).


> It's just the custom formatting which isn't
> there yet, but that's going to be templated, so it shouldn't pull in any
> additional symbols unless it's used.


Please check and see if additional symbols are pulled in or not. I've seen a lot 
of template code where the author of that code never checked and was surprised 
at the instantiations that were happening that he overlooked.