Proposal for custom time string formatting in std.datetime
    Jonathan M Davis 
    jmdavisProg at gmx.com
       
    Thu Dec 22 01:04:28 PST 2011
    
    
  
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.
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. 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.
- Jonathan M Davis
    
    
More information about the Digitalmars-d
mailing list