Proposal for custom time string formatting in std.datetime

Jonathan M Davis jmdavisProg at gmx.com
Thu Dec 22 19:24:27 PST 2011


On Thursday, December 22, 2011 10:29:59 Michel Fortin wrote:
> I'd tend to say that for general purpose time representation not
> involving local time, SysTime is suboptimal because it forces you to
> carry around a pointer to a time zone. Imagine an array of SysTime all
> in UTC and the space wasted with all those pointers referencing the UTC
> time zone object.
> 
> It should be very easy to make a separate type, let's say UTCTime, and
> allow SysTime to be constructed from it and to be implicitly converted
> to it (with alias this). Then put UTCTime in a different module from
> SysTime and you can deal with time in UTC without having to ever import
> the module with SysTime the time zone class it wants.
> 
> Then redefine all APIs not dealing with local time so they work with
> UTCTime instead of SysTime.

That could certainly be done, but it complicates things that much more. The 
idea, at least, of SysTime was that it would deal with all of the time zone 
stuff correctly without you having to worry about it unless you wanted to deal 
with the time zone stuff, in which case it would give you those capabilities. 
That requires having it to carry the time zone around.

Something like UTCTime would allow you to carry the time around without the 
time zone, but then anyone who wants to be able to do stuff like convert it to 
a string or get its year or anything like that is almost certainly going to 
want it in a particular time zone (probably local time) rather than UTC, so it 
increases the burden on the programmer to deal with something like UTCTime. If 
you're dealing with anything beyond comparing times or adding durations to 
them, you're going to need the time zone, and in most cases, UTC is not the 
one that people are going to want.

So, it harms usability IMHO to using something like UTCTime instead of 
SysTime, and just to save yourself the cost of the reference for the time 
zone? If you're _that_ worried about the space, you can always use a SysTime's 
stdTime property or toUnixTime and get an integral value to store. Granted, 
that's not as safe as something like UTCTime, since it's a naked number, but I 
really don't think that the cost of that reference is generally an issue.

- Jonathan M Davis


More information about the Digitalmars-d mailing list