[DB-SIG] Re: ANN: DateTime type, version 0.1

[Jeffrey C. Jacobs]

-----Original Message-----
From:	M.-A. Lemburg [SMTP:lemburg@uni-duesseldorf.de]
Sent:	Saturday, December 13, 1997 4:40 PM
To:	DB-SIG @ Python.org
Subject:	[DB-SIG] Re: ANN: DateTime type, version 0.1

Some questions regarding further developements:

2. Though not needed for DB interfacing, it would be nice to have
a way to express deltas in time (e.g. +2 months, -3 seconds, etc.).
These objects will hold relative data, so calculating a specific
fixed number of seconds/days as internal basis is not possible,
because e.g. a month can have 28,29,30 or 31 days. Example:

t1 =3D maketime(1997,12,12)
t2 =3D maketime(1998,2,1)
d =3D DateTimeDelta(month=3D+2)

Possible keywords for the constructor:
 relative:
  year,month,day,hour,minute,second - add values to resp. fields
 absolute difference:
  absdate - add value to absdate, fractions are added to abstime
  abstime - add value to abstime, overflow is added to absdate

(The two categories mutually exclude each other, e.g. if you use
 month=3D+2,day=3D+2 you can't use absdate=3D+30)

t1 + d will point to 1998,2,12
t2 + d will point to 1998,4,1

Questions:
- What is the outcome of maketime(1997,12,31) + d ? Since february
  doesn't have 31 days the new date is not well defined. I guess
  an exception should be raised to indicate this.
- What should t2 - t1 result in ? There are two options:
  a) it returns a relative result like =
DateTimeDelta(year=3D+1,month=3D-10,
     day=3D-11)
  b) it returns an absolute difference, DateTimeDelta(absdate=3D+51)
  I think arithmetic should always use option b). Option a) could
  be returned by a special reldifftime() function.
- Is there a need for addition of deltas ?=20
- Would having seperate types for the two flavors (relative and
  absolute) be a better approach. [actually while writing this, I
  tend to think so].

--=20
Marc-Andre Lemburg

[The TimeHorse] =20
	Just to go over some of the Questions raised, as far as Months are =
concerned, 31 Jan 1998 + 1 Month =3D 28 Feb 1998 seems at least to me =
the most intuitive approach.  If I wish to increment the month field, I =
certainly do not expect the Day to change.  Thus, if 31 Feb 1998 doesn't =
exist, try 30 Feb, then 29 Feb and finally 28 Feb, basically reducing to =
the last date.  Again, problems with commutative and closure arise, as =
31 Jan 1998 + 1 month + 1 month =3D 28 March 1998, but 31 Jan 1998 + 2 =
months =3D 31 March 1998.  The only way around this I can think of is to =
hide the days lost due to the increment in a separate internal and add =
them back if the month is change again.  Thus:

Initially:
	DaysFromMonthLost =3D 0
	Date =3D 31 Jan 1998
Date =3D Date + 1 month:
	DaysFromMonthLost =3D 3
	Date =3D 28 Feb 1998
Date =3D Date + 2 months:
	DaysFromMonthLost =3D 1
	Date =3D 30 Apr 1998
Date =3D Date + 3 months:
	DaysFromMonthLost =3D 0
	Date =3D 31 Jul 1998
Date =3D 31 Jan 1998
	DaysFromMonthLost =3D 0
	Date =3D 31 Jan 1998
Date =3D Date + ( 31 Days * 6)
	DaysFromMonthLost =3D 0
	Date =3D 5 Aug 1998

Note, this is *not* the same as adding 31 days for each month.  In fact, =
if the user wants to add 31 days for each month, why not just explicitly =
add 31 days?  The user can even define a constant, MyMonthLength =3D 31 =
days.  Also, we have this problem with:

Initially:
	DaysFromMonthLost =3D 0
	LeapSecondLost =3D 0
	DT =3D 30 Jun 1997, 23:59:60
DT =3D DT + 1 day
	DaysFromMonthLost =3D 0
	LeapSecondLost =3D 1
	DT =3D 1 July 1997, 23:59:59
DT =3D DT - 1 day
	DaysFromMonthLost =3D 0
	LeapSecondLost =3D 0
	DT =3D 30 Jun 1997, 23:59:60

It seems that month and in the case of the leap second day are the only =
fields which due to their inconsistent nature in the Gregorian calendar =
will cause problems in "lower" fields, which is the crux of the problem =
here.  And certainly as soon as the lower field is directly modified, =
how does that effect our DaysFromMonthLost and LeapSecondLost values?  =
For instance:

Initially:
	DaysFromMonthLost =3D 1
	Date =3D 30 Jun 1998
Date =3D Date + 1 day
	??? DaysFromMonthLost =3D 0
	??? Date =3D 30 Jun 1998
???
	??? DaysFromMonthLost =3D 1
	??? Date =3D 1 Jul 1998

I lean towards the latter possibility, and the only way to empty our =
DaysFromMonthLost and LeapSecondLost value is to apply another Month or =
Day addition respectively, which will cause the hidden members =
DaysFromMonthLost and LeapSecondLost to diminish under the circumstances =
described above.  Of course, one can imagine successive 31 May 1998 + 1 =
month - 30 days operations=20
increasing DaysFromMonthLost astronomically over successive operations.  =
Perhaps the simplest case is to clear the hidden values each time a =
lower-order time value is changed, and make the change as normal, i.e. =
above:

	??? DaysFromMonthLost =3D 0
	??? Date =3D 1 Jul 1998

Again, I think the most important issue, apart from avoiding the 31 day =
month constant (which since it is already supported in the days field, I =
feel is not a good interpretation of the month field), DateTime and =
DateTimeDelta math should hold for Commutativity, Associativity and =
Closure.  Certainly, having these hidden fields allow for these to work =
in some circumstances, but clearly not all.

	As far as the second question raised, I agree with Marc-Andre's comment =
that differences should be in absolute dates, but with the option of a =
higher-level interpretation.  This is an important issue, as if =
DateTimeDeltas purely store absdate and abstime, then how does one =
initialize such an object to 1 month anyway?  Thus, perhaps one needs a =
separate type of DateTimeDelta object than the one which is a simple =
absdate, abstime pair.  DateTimeDelta I think should remain the simple =
days, seconds pair, but perhaps support for the 9-tuple time object may =
also be necessary.  That way, you may also use the week field for a + 1 =
week operation.  Again, I won't even touch the can of worms you have =
with the Mayan or Hebrew calendars, should they be used.  :)

	As for addition of Deltas, I don't think this is such a bear if the =
DateTimeDelta is the simple absdate, abstime pair.  Thus I weigh in on =
supporting this, and certainly my views on a separate DateTime and =
DateTimeDelta class are well-known.  :)

			Be Seeing You,

			Jeffrey.

---
~,-;`  The TimeHorse
Sometimes also a Dragon. . .


 

_______________
DB-SIG  - SIG on Tabular Databases in Python

send messages to: db-sig@python.org
administrivia to: db-sig-request@python.org
_______________