Please vote on std.datetime

[Jonathan M Davis]

On Friday 10 December 2010 03:18:29 Fawzi Mohamed wrote:
> On 10-dic-10, at 01:26, Andrei Alexandrescu wrote:
> > Jonathan M. Davis has diligently worked on his std.datetime
> > proposal, and it has been through a few review cycles in this
> > newsgroup.
> > 
> > It's time to vote. Please vote for or against inclusion of datetime
> > into Phobos, along with your reasons.
> > 
> > 
> > Thank you,
> > 
> > Andrei
> 
> I think it is quite complete and usable, lot of work obviously went
> into this,...
> an clearly after the praise comes a "but"... so here are my comments
> on it, some are just personal preferences
> 
> - I would split the unittests to a separate test module, I like having
> unittests, but having many of them make the code more difficult for me
> to skim through, and grasp, one test (example) can be useful, but lots
> of the hide the code structure.
> Maybe it is just my personal preference, but I like compact code, code
> that can be read, and so many unittests stop the flow of my reading.

This has been discussed a time or two. D really isn't set up to work that way. 
Yoo can't just move them over because then those that need private access won't 
work. The lack of named unittest blocks really hurts that as well. You _could_ 
turn them into mixins of some kind, but that could get quite messy.

But honestly, I find it _way_ easier to maintain the code with each unittest 
block immediately following the function that it's testing. The interval code is 
quite irritating precisely because I couldn't put the tests next to the code 
(since it's templatized it just didn't work in that case). I agree that it does 
harm your ability to skim through the code, but the ddoc html files let you skim 
the API, and I really di think think it's more maintainable this way. Besides, 
if we really want to, we can change that sort of thing later. Exactly how the 
unit tests are handled doesn't affect the public API or the general useability of 
the module.

> - I would split this into several modules
> (Timezone,SysTime,TimeDate,Clock), and if you want a "helper" module
> that make a public export.
> Modules should be used to define modules/namespaces, using classes
> seems a misuse to me (I am looking a Clock for example, which is a
> separated functionality imho).

It was already discussed that it would be better as one module. We don't have 
any kind of hard limit on the size of modules or anything like that, and it's 
just simpler to have it in one module.

Clock is used as a namespace of sorts specifically to make the code clearer. You 
can think of it as a sort of singleton which has the functions which give you 
the time from the system clock. I think that it improves useability.

Similarly, IRange is there specifically to namespace the functions which generate 
functions used to generate ranges. It makes the code clearer to make it clear 
that the functions are generating range generative functions.

There were other classes used to namespace code, and it was rightly pointed out 
that they were unneeded. However, I believe that in these two cases, it's a 
definite useability improvement to have them. It makes code clearer and easier to 
read.

> - I find that there is a loss of orthogonality between SysTime and
> DateTime. For me there are a calendar dates, and absolute points in
> time. To interconvert between the two one needs a timezone. I would
> associate the timezone with the calendar date and *not* with the
> absolute time.
> I find that SysTime makes too much effort to be a calendar date
> instead of a "point in time".
> Also if one wants to use a point in time at low level it should be
> "lean and mean", what is the timezone doing there?

I don't really get this. Date and DateTime (and thus TimeOfDay) is intended for 
calendar use. There is no time zone because you're not dealing with exact times 
which care about the time zone that they're in. They don't necessarily have any 
relation to UTC or local time. A lot of calendar stuff isn't going to care one 
whit about time zones.

SysTime is specifically supposed to handle the "system time." The system 
definitely cares about the time zone. You have a local time zone that your system 
is in. You potentially have to convert between time zones when playing around 
with time stamps and the like. It's when dealing with the system time that 
you're really going to care about time zones. So, SysTime includes a time zone, 
and it is the type to use when you care about the time zone. If you really want 
dealing with the system time to work correctly in the general case, you need it 
to have a time zone. I've run into a number of bugs at work precisely because 
time_t was passed around naked and constantly converted (which, on top of being 
bug-prone, _cannot_ work correctly due to DST). By having the time in UTC 
internally at all times and converting it as necessary to the time zone that you 
want, you avoid a _lot_ of problems with time.

> Last thing, well is something I would have done differently (as I said
> already in the past), is using doubles expressing number of seconds to
> represent point in time, durations, and TimeOfDay. I know other
> differs about this, but I really think that it is a very simple and
> versatile type.

doubles aren't precise. And having the units associated with a duration rather 
than having a naked number really helps to avoid bugs due to programmers 
assuming the wrong units for times.

- Jonathan M Davis