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
