[phobos] datetime review

Jonathan M Davis jmdavisProg at gmx.com
Fri Oct 8 22:47:31 PDT 2010


On Friday 08 October 2010 22:30:02 Walter Bright wrote:
> >  So, they are distinct (the concepts are from Boost). There are
> > 
> > multiple duration types primarily because you can't convert between
> > months and small units without a specific date, so you can't convert
> > something like 5 months to days without knowing which months you're
> > dealing with.
> 
> True, but why would a month be a type other than int?

Sure, a MonthDuration holds the number of months internally as an integral 
value, but if you have an int floating around by itself, it doesn't have any 
units, and the programmer has to worry about what the int actually means. They'd 
then have to worry about the conversions between various units of time (month, 
day, hour, etc.). The duration structs deal with that for you.

Even worse, what would it mean to add a naked number to a time point? If you add 
7 to a date, what does that mean? And even if everyone agreed that it was clear 
that adding 7 to a date meant adding 7 days to it, adding 7 to a time of day 
wouldn't mean the same thing, so that naked number could mean very different 
things when added to two different types of time point. By having a duration type 
which includes the units, it's taken care of for you. You won't try and add 
months to time of day, because it won't compile. And if you try and add days to 
it, it will mean exactly the same thing as if you added days to a date (much as 
adding days to a time of day is relatively pointless). Overall, it should make 
the programmer's life easier rather than harder.

> >  However, I have
> > definite worked on making it so that you don't have to worry about the
> > multiple duration types in most cases. You'd do something like
> > Dur.years(5) + Dur.days(2) to create a duration of 5 years and 2 days,
> > and you don't have to know or care what the duration types are.
> 
> Ok, but I don't see that requires more than one duration type.

The problem with month vs smaller units is that you can't do _any_ conversion 
between them without a specific date. So, you can't have a duration that holds 
both months and days. Sure, when you subtract two dates, you have the 
information to do the conversion to smaller units, so you can have their 
difference be in days or seconds or whatever. But if you create durations 
directly - e.g. Dur.months(5) - then you have no way of converting the number of 
months to smaller units in order to be able to add the two durations together.

MonthDuration holds months and HNSecDuration holds hecto-nanoseconds (100 ns). 
There is no way to take those two and turn them into one type or to add the two 
of them together and result in a duration of either type (which is why 
JointDuration holds both rather than actually trying to add them together). 
There's no conversion. Once you add them to a specific time point, _then_ it's 
possible, but free-floating months and days can't be added together.

> > There are multiple time zone classes because it uses polymorphism to deal
> > with the rules for a given time zone. The really basic LocalTime and UTC
> > deal with most cases, but for anyone who really needs to deal with
> > multiple time zones, PosixTimeZone and WindowsTimeZone will be
> > invaluable (I'd love to only have one of those, but Windows just doesn't
> > deal with time zones like the Posix world does).
> 
> I agree some kind of polymorphism for time zones is necessary. [rant]
> Timezones should be an operating system service, if for no other reason
> than it sucks to have all your apps break when some tinhorn country
> decides to change their daylight savings time, etc.[/rant]

Which is why PosixTimeZone and WindowsTimeZone will be getting that information 
from the OS, but the OS does not make it easy. On Posix, you have to actually 
read in the time zone files from disk, and on Windows, you have to read the 
registry. No system calls are provided to properly deal with time zones. 
Honestly, time zone support for anything other than the local time zone is very 
poor on both Posix and Windows systems. And Windows won't even let you set the 
time zone for your program without setting for the whole OS. It's not a pleasant 
situation really, but I hope to be able to overcome it well enough that D 
programmers won't have to worry about it.

- Jonathan M Davis


More information about the phobos mailing list