[DB-SIG] Assuming larger time scope

[Jeffrey C. Jacobs]

-----Original Message-----
From:	Magnus Lycka [SMTP:magnus.lycka@tripnet.se]
Sent:	Tuesday, December 16, 1997 6:45 AM
To:	DB-SIG @ Python.org
Subject:	[DB-SIG] Assuming larger time scope

First of all, I suggest that definitions with 'holes' like maketime(,1,,,15,)
should be rejected. An incomplete time definition should at least contain
all the digits from its LSD to its MSD. As I said, the undefined values to the
right of the defined stuff should be set to minimum values.
maketime(1965,,,,,)
should mean maketime(1965,1,1,0,0,0). When there are undefined values to the
left of the indicated ones, I suggest they are assumed to be _as_close_as_
_possible_ to the current time. In other words, writing maketime(,,1,,,) on
the coming christmas eve should mean 1998,1,1,0,0,0. This makes the module
sane for handling things like maketime(65,01,01,12,20,) for my birth,
maketime(924,7,8,,,) for my father's birth date, maketime(15,,,,,) for my
50th birthday (well, 51st really ;-) without having to use 4 digits for years
that are close to today.

[The TimeHorse]  One thing I would suggest is that the
month interpolation need not be so complicated as rounding
to the nearest date.  Probably in such cases where the month
is left blank to fill in the month with the current month.
Certainly, in a lot of circumstances I might mean the last
"first of the month", say if I wanted to keep track of when
my mother last visited, and sometimes I'd want to interpolate
to the next "first of the month", when my rent is due.  Thus,
for simplicity, I'd just suggest use the current month.
[End TimeHorse]  

Then we come back to the varying lenght of the month... (Maybe it wouldn't
be a bad idea to try to move earth after all? ;-) If someone enters
(,,31,23,59,59) on now=(1998,3,1,4,0,0), what do they refer to?
(1998,1,31,23,59,59) is the closest, and (1998,3,31,23,59,59) is the next,
but one could also imagine that they really wanted (1998,2,28,23,59,59),
just as we might assume that one month after Jan 31 is Feb 28.

[The TimeHorse]  In this case, I think most applications let
the date spill over into the next month.  Thus (,,31,,,) in
February 1998 would evaluate to 3 March 1998.
[End TimeHorse]

In a way I could imagine having (,-1,,,,) meaning the last day of the month,
just as x[-1], but on the other hand, that's not really a KISS approach...

[The TimeHorse]  This would be a good way of solving the
whole last of the month issue when we add months.  A shame
we can't make a distinction between the 31st of January
and the last day of January.  When adding a month to it,
this is a big issue.  Agreed, though: it is a can of worms!
[End TimeHorse]
 
OUCH! I just realized a significant problem! If year is an integer, there
is no way of differentiating 8 (which should mean 1998) and 08 (which should
mean 2008)! I think this is a problem of some significance. I can only see
three solutions to that, and all are ugly:
1) use strings (that would make it possible to parse month names I guess)
2) add an extra value to indicate how many digits are valid in year:
   2,8 => 08 => 2002; 1,8 => 8 => 1998.
3) Make year into four tuple instances instead of one 1997 => 1,9,9,7

[The TimeHorse]  One issue I would point out even more so
is that there is always *some* way of entering any date
in the 20th and 21 centuries if we just type it out fully,
but if we allow abbreviations, such as even '98, how do I
know I don't mean 98 AD?  It is quite possible, even if
unlikely that I wish to enter a date of that type, and by
allowing abbreviation we have eliminated *any* way of
entering such a date.  I think the easiest thing to do is
to force the user to write out the date in full, as that
is the best way I can think of to also allow input of small
dates.  At the very least, we need to have some method of
entering small dates, such as 98 AD
[End TimeHorse]
 
			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
_______________