On 2011-12-22 11:03:13 +0000, Jonathan M Davis <[email protected]> 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
[email protected]
http://michelf.com/
