On 10-dic-10, at 18:02, Jonathan M Davis wrote:
thanks for the answers
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.
ok, sorry I hadn't followed the discussion, as I said that is just my
personal perference.
- 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.
well but with public export you can easily have an exported module, by
separate compilation you might spare something, but again it is a
matter of style, I find that in d the main way to partition code are
modules.
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.
having a separate module for it would give a similar effect
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.
if I alone on this I will not argue, but I definitely have a different
style.
- 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.
I see two uses of time, one is calender the other a point in time.
A point in time needs only to know if other events are before or after
it, or how far they are.
It should definitely use a unique reference point (for example NSDate
uses 1 january 2001).
Using UTC is correct, I never argued for something else.
the thing is that a point in tame doesn't *need* a timezone, it needs
just a reference point.
A timezone is needed to convert between calender (TimeDate) and a
point in time.
So if one wants to store a timezone somewhere (and not use it just
when converting between point in time and calender date), then I would
store it in calender date, because without it I cannot know to which
absolute time it refers, and a calendar date is already larger, and
the extra storage is probably not something one would care in typical
use of the calendar.
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.
ms accuracy over more than 100'000 years, and much higher for smaller
ranges doesn't seems to imprecise to me, and having *only* seconds
with them should not confuse people. I don't argue against having
functions using ints, but I think that having also a double based
interface and using it internally for point in time, and timeofday,
and at least having it as option (i.e. function returning the value)
for normal durations would be good.
I agree that for calender and calender differences it is not the best
choice, but a calendar is not what is used at a low level (to set an
alarm for example), one should not force the calendar issues on the
more basic point in time.
Fawzi
