Proposal for custom time string formatting in std.datetime

Michel Fortin michel.fortin at michelf.com
Thu Dec 22 07:29:59 PST 2011


On 2011-12-22 11:03:13 +0000, Jonathan M Davis <jmdavisProg at gmx.com> said:

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

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.

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



More information about the Digitalmars-d mailing list