Please vote on std.datetime

[Fawzi Mohamed]

On 10-dic-10, at 20:07, Jonathan M Davis wrote:

> On Friday, December 10, 2010 09:55:02 Fawzi Mohamed wrote:
>> 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:
>>> 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
>
> Having a separate module would defeat the point at least in part.  
> The idea is
> that you call Clock.currTime() rather than currTime(). You call
> IRange.everyDayOfWeek!() instead of everyDayOfWeek!(). The benefit  
> is in having
> the extra name to make it clear what the function is associated  
> with, what it's
> doing. For instance, conceptually, you're getting the current time  
> from the
> system clock. This makes it explicit. If it were a separate module,  
> then it
> would normally just be imported and you'd call currTime() and  
> everyDayOfWeek!()
> and all the benefit of putting them in that separate namespace is  
> lost.
import Clock=std.time.Clock;

Clock.currTime();
>
>>>> - 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.
>
> We're obviously thinking of very different use cases here. A SysTime  
> is a specific
> point in time. It's exact. You can't possibly mistake it for any  
> other point in
> time ever. It can effectively be displayed and manipulated in a  
> particular time
> zone, but it is an exact point in time with no ambiguity.

That is *exactly* my point SysTime is a point in time *not* a  
calender, the current apy tries too hard to make it behave like a  
calender, and the presence of a timezone in there reflects this
>
> DateTime, on the other hand, could represent over 24 different  
> points in time
> (and that's assuming that it doesn't hit a DST transition). It is  
> not at all
> exact. It's exact enough for manipulating general dates and times,  
> but it's not
> exact enough for doing anything that is concerned with being an  
> unambiguous
> point in time. Sure, it _could_ be made to have a time zone, but  
> that would
> complicate it further, and many uses wouldn't care at all. It's not  
> associated
> with machine/system time at all. It's a conceptual point in time but  
> is not an
> actual, exact point in time in the manner that SysTime is.

Then timezone should be only in the conversion routines between  
SysTime and DateTime.

> SysTime is intended for anything that cares about machine/system  
> time and/or
> dealing with exact, unambiguous points in time. Date/TimeOfDay/ 
> DateTime are
> intended for calendar-based operations and aren't intended to need  
> to care about
> exact, unambiguous times in the same manner. True, some calendar  
> applications
> may care about time zone, but they can keep track of that and  
> convert them to
> SysTimes if necessary.

Again there is no reason to have a timezone in SysTime, probably it  
should be just in the conversion routines, and if one really wants to  
have it somewhere then I argue that it is better to put them in  
DateTime (makeing it behave like a point in time) rather than in  
SysTime (as now, making it behave like a calendar).

> By having SysTime, the default time type deals with time zones and  
> DST correctly
> without the programmer having to worry about it. That is _not_ true  
> if the time
> zone is not part of the equation.

what do you mean either one has to pass the timezone (and thus worry  
about it) or use the default one, how is that different from passing  
the timezone or not to a conversion routine?

>
> - Jonathan M Davis