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