Please vote on std.datetime

[Jonathan M Davis]

On Friday, December 10, 2010 15:29:40 Fawzi Mohamed wrote:
> 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();

Except then you have to go out of your way to do that. It's no longer the 
default.

> >>>> - 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?

Converting time back and forth is _bad_, _really_ bad. It does _not_ work in the 
face of DST (some times exist twice while others don't exist at all). By 
specifically having a type which holds the time in UTC at _all_ times but which 
allows you to operate on it assuming a particular time zone, you are able to 
have the time be correct and yet still operate in your local time zone (or 
whatever other time zone that you wish to operate in). It fixes time conversion 
problems. If you're constantly converting back and forth between DateTime and 
SysTime, you _will_ have conversion problems.

SysTime is intended to hold an exact time with a time zone, so that you have an 
unambiguous time which is actually able to be used in your local time without 
doing any conversions.

Date/TimeOfDay/DateTime are intended for calendar operations which do not care 
about time zone. All of the operations on DateTime can be done on SysTime (and 
most of the operations on SysTime can be done on DateTime) if you want a time 
zone - they're just considerably less efficient.

DateTime gives you a type which allows for calendar operations to be efficient 
(like getting the current day or adding a month to a date), unlike SysTime where 
its operations are optimized for dealing with the OS. If you want to do calender 
operations efficiently and yet still have a time zone, then you're going to have 
to keep track of what time zone you're dealing with for when you convert it to a 
SysTime. Unfortunately, because DateTime is _not_ in UTC but is a generic time, 
there can be conversion problems when converting to a SysTime for a time which 
is during a DST switch. But if it were in UTC, then it wouldn't be a generic 
date or time any longer, and the calendar operations would no longer be as 
efficient because conversions would have to be done everywhere.

SysTime is pretty much the entire reason that I wanted to write std.datetime. By 
having both the time in UTC and the time zone in a single type, it is possible 
to correctly handle time in the face of time zone and DST changes. I'm sick of 
having to fix bugs relating to converting time. I want D to do it right.

Date exists because I originally based std.datetime on the Boost API (which has 
a date class), and because I thought that it would be worthwhile to have a date 
type which was efficient for date/calendar operations. Having that, it seemed 
useful to have one which included the time and was efficient for calendar 
operations. So, I created TimeOfDay and DateTime. The entire purpose of 
Date/TimeOfDay/DateTime is to have types which are efficient for calendar 
operations and which don't care about time zones. You're dealing with a date 
and/or time which is generic and is not an absolute point in time - it has a 
time zone or insists on being in UTC (which would make pretty much all of their 
operations less efficient).

SysTime is the type you use for getting the system time. It is the type that I 
expect to be used the most. It's the type that functions like 
std.file.lastModified() will use. Date, TimeOfDay, and DateTime exist for cases 
where people are interested in efficient calendar operations, don't care about the 
connection between that date/time and the system time, and don't care about the 
time zone. You can convert between the two but the risk the run of conversion 
problems whenever DST changes.

I believe that you're the first to complain about how SysTime has a TimeZone and 
DateTime doesn't, so I don't get the impression that folks in general have a 
problem with that (though it could just be that not enough people have read the 
code). But the use case for SysTime calls for a time zone whereas the use case 
for Date/TimeOfDay/DateTime doesn't. I think that the problem is that you're 
just thinking about calendars and what calendar time indicates differently than I 
am.

- Jonathan M Davis