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. > >> - 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. 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. 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. 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. - Jonathan M Davis
