Proposal for custom time string formatting in std.datetime
Jonathan M Davis
jmdavisProg at gmx.com
Wed Dec 28 03:03:30 PST 2011
On Wednesday, December 28, 2011 11:39:16 Kagamin wrote:
> On Wednesday, 28 December 2011 at 00:15:00 UTC, Jonathan M Davis
>
> wrote:
> > By having SysTime, you don't need extra time types.
>
> Hmm... if you don't have extra time types, how do you format a
> SysTime? To convert a SysTime to a string you usually need year,
> month and day. Calculating a year takes some time: leap years,
> possibly time zone adjustment; when you need month, you have to
> recalculate year, since SysTime doesn't hold it. That's how it
> works?
SysTime's time is held internally as a long holding the number of hecto-
nanoseconds (100 ns) from midnight, January 1st, 1 A.D. It also holds a
TimeZone which is used to convert that time to the correct time zone when any
function requires that the time be in a specific time zone (e.g. getting the
year of the SysTime or converting it to a string). SysTime does all of the
appropriate calculations for that. And if you want to change the time zone of
a SysTime, you set its timezone property to the TimeZone that you want. Its
internal time is always in UTC.
And yes, if you access any function or property of SysTime which needs the
time in any format other than hnsecs from midnight January 1st, 1 A.D., it has
to do the appropriate calculations, even if it's done them before. That's why
it can be more efficient to convert a SysTime to a DateTime if you need access
its properties a bunch of times in a row. But as long as you don't create a
SysTime from that DateTime, you shouldn't have conversion problems.
You _do_ have potential conversion issues if you set a property on a SysTime
(e.g. the year), since it has to convert it to its time zone and back again to
do that, but there's no way around that unfortunately. However, adding and
subtracting durations from a SysTime have no problems at all, because you
don't have to do any conversions. It's just setting a property that must be in
the SysTime's time zone (e.g. the year or month) which could have conversion
issues.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list