[DB-SIG] Assuming larger time scope

[M.-A. Lemburg]

Jeffrey C. Jacobs wrote:
> 
> -----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
> ...
> 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]

Not so the next version of DateTime. It checks the day of the month
and raises an exception if it doesn't fit the given month.

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

I've added the -1 (last day of the month) feature to
maketime(). It will get converted to the real day though,
so the "last day of the month" information is lost after
initialization. But it is still useful for doing the exception
handling I pointed out in another post.

-- 
Marc-Andre Lemburg


_______________
DB-SIG  - SIG on Tabular Databases in Python

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