Please vote on std.datetime

[Fawzi Mohamed]

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