[DB-SIG] Assuming larger time scope

[Magnus Lycka]

Still brain storming... I have to admit that I haven't read all the
source that people have referred to recently. I hope that doesn't
make the things I write seem all to stupid.

Actually, the further I get into this, the more I feel that this might
be something for a subclass, rater than the base class.

Assuming the construction maketime(year,month,day,hour,minute,second)
we can make some assumptions if not all fields are filled. For instance
if hour and minute are filled and the rest is left empty, one might
certainly assume that seconds should be 0. What should one assume about
the date? The trivil assumption would be to assume that it's todays date.
But I'm not sure you should always to that.

This can also be drawn further: If day is entered, we assume that this
month and year is what we are looking for and so on. For this to be logical
the same should be assumed for the digits in the year (even though theys are
in one variable) since the individual digits are positional items in another
way than the two digits in for instance month is. We do write 97 for 1997, but
never 2 for december, or 5 for the 25th day of the month.

Naturally, this makes us think of the approaching millenium shift. If we write
year = 00 today, it's unlikely that we mean 1900, and certainly 002 is more
likely to refer to 2002 than 1002.

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.

So, if it's (1997,12,16,11,58,00) now and someone enters (,,1,,,) this should
either be interpreted as t1=(1997,12,1,0,0,0) or t2=(1998,1,1,0,0,0). Then the
actual time should be:

entered_time = self.tuple
t = entered_time.fill_min_values_after() #Zeroes except 1 for month and day
t1 = t.fill_in_present_values_before()   #Start with now and overwrite w/ t
if t1 < now:
    t2 = t.fill_in_next(t1)              #Next time after t1 that matches t
else:
    t2 = t1
    t1 = t.fill_in_previous(t2)
if (now - t1 > t2 -now):
    t = t2
else:
    t = t1

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.

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


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

I guess this is really just an issue when we are parsing input, and in that
case the string is what we start with anyway. Maybe this don't have anything
to do in the date base class at all. Maybe this parsing should be a function
that the entry widgets or input file parsers should call before saving a
date.

--
Magnus Lycka, S/W Engineer, M.Sc.E.E; Folktrov. 6C, 907 51 Umea, Sweden
Tel: +46(0)90 198 498, GSM: +46(0)70 582 80 65, Fax: +46(0)70 612 80 65
<mailto:magnus.lycka@tripnet.se>         <http://www1.tripnet.se/~mly/>


_______________
DB-SIG  - SIG on Tabular Databases in Python

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