Proposal for custom time string formatting in std.datetime

[Michel Fortin]

On 2011-12-23 03:24:27 +0000, Jonathan M Davis <jmdavisProg at gmx.com> said:

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

Well, what I'm getting at is that most of the time you don't care which 
time zone the time was recorded in, so you don't need to attach a time 
zone to it, you only need to take the time zone into consideration when 
formatting as a string, and then you mostly always use local time.

The real issue remains that you can't use SysTime without including all 
the code for all the time zones. Think about this: if you don't need to 
carry around the time zones but instead only ask for a time zone when 
formatting as a string, you much less need time zones to be 
polymorphic. The time zone could be a template argument to the 
formatting functions for instance.

On the other hand, if you need to carry the associated time zone along 
with the time, then things gets more complicated and a polymorphic time 
zone type tend to solve that problem well. But how many of us need to 
carry a time zone with a time value?

So in my opinion associating a time zone with SysTime was a mistake. 
Not just because it forces you to carry around an extra pointer, but 
mostly because it forces time zones to be polymorphic which brings all 
the drawbacks of a class: less inlining and worse performance due to 
virtual functions, and all the virtual functions need to be included in 
the binary even if you don't use them. It does benefit the use case 
where you need to tag a time with a specific time zone, but that sounds 
rather specialized to me.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/