Proposal for custom time string formatting in std.datetime

[Jonathan M Davis]

On Thursday, December 22, 2011 02:12:31 Walter Bright wrote:
> Timezone information is not necessary to measure elapsed time or relative
> time, for example.

The type requires it though. No, comparison doesn't require the time zone, but 
many (most?) of the other operations do. And the type can't be separated from 
the time zone. That's part of the whole point of how SysTime is designed. It 
holds its time internally in UTC and then uses the time zone to adjust the 
time whenever a property or other function is used which requires the time in 
that time zone. That way, you avoid all of the issues and bugs that result 
from converting the time. The cost of that is that you can't not have a time 
zone and use SysTime. So, if someone cares about saving that little bit of 
extra size in their executable by not using the time zone, they're going to 
have to use the C functions or design their own time code.

> 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).

I don't follow you. You mean use PIMPL for the time zone? I haven't a clue how 
you're going to do PIMPL without .di files, and Phobos doesn't use .di files 
(and arguably _can't_, because it would destroy inlining and CTFE). Not to 
mention, PIMPL would make SysTime less efficient, because in order to avoid 
needing to know what the functions are on a TimeZone, you'd have to hide the 
bodies of a number of SysTime's functions, which would disallow inlining and 
CTFE (not that CTFE is terribly likely to be used with SysTime, but inlining 
could be very important). You'd be losing efficiency of execution just to save a 
few KB in the executable.

Rearranging stuff to save some size in the executable without costing efficiency 
is one thing, but if it's going to cost efficiency, then I'm generally going to 
be against it.

> 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.

Nothing would pull in toCustomString or fromCustomString in unless the user 
decided to call them, because they're templated and no other functions in 
Phobos are going to use them at this point (if ever). What exactly will be 
pulled in when they _are_ called, I don't know, because they're not completed 
yet. It probably wouldn't be much though, since toCustomString is basically a 
fancy toString. But there's a good chance that it's stuff that's already being 
pulled in for the standard string functions (e.g. toISOExtString).

- Jonathan M Davis