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