Commit Graph

77 Commits

Author SHA1 Message Date
Tim Peters 710fb1548a astimezone() internals: if utcoffset() returns a duration, complain if
dst() returns None (instead of treating that as 0).
2003-01-02 19:35:54 +00:00
Tim Peters c5dc4da125 The astimezone() correctness proof endured much pain to prove what
turned out to be 3 special cases of a single more-general result.
Proving the latter instead is a real simplification.
2003-01-02 17:55:03 +00:00
Tim Peters 5d644dd25a SF bug 661086: datetime.today() truncates microseconds.
On Windows, it was very common to get microsecond values (out of
.today() and .now()) of the form 480999, i.e. with three trailing
nines.  The platform precision is .001 seconds, and fp rounding
errors account for the rest.  Under the covers, that 480999 started
life as the fractional part of a timestamp, like .4809999978.
Rounding that times 1e6 cures the irritation.

Confession:  the platform precision isn't really .001 seconds.  It's
usually worse.  What actually happens is that MS rounds a cruder value
to a multiple of .001, and that suffers its own rounding errors.

A tiny bit of refactoring added a new internal utility to round
doubles.
2003-01-02 16:32:54 +00:00
Tim Peters c3bb26a099 Completed astimezone's correctness proof. That doesn't mean it's
correct by your lights, it means that-- barring coding errors --it
implements what it intended to implement.
2003-01-02 03:14:59 +00:00
Tim Peters f36151556f A quicker astimezone() implementation, rehabilitating an earlier
suggestion from Guido, along with a formal correctness proof of the
trickiest bit.  The intricacy of the proof reveals how delicate this
is, but also how robust the conclusion:  correctness doesn't rely on
dst() returning +- one hour (not all real time zones do!), it only
relies on:

1. That dst() returns a (any) non-zero value if and only if daylight
   time is in effect.

and

2. That the tzinfo subclass implements a consistent notion of time zone.

The meaning of "consistent" was a hidden assumption, which is now an
explicit requirement in the docs.  Alas, it's an unverifiable (by the
datetime implementation) requirement, but so it goes.
2003-01-01 21:51:37 +00:00
Tim Peters b5a16f3375 datetimetz_astimezone(): Speed optimizations -- although I'd rather
find a more elegant algorithm (OTOH, the hairy new implementation allows
user-written tzinfo classes to be elegant, so it's a big win even if
astimezone() remains hairy).

Darn!  I've only got 10 minutes left to get falling-down drunk!  I suppose
I'll have to smoke crack instead now.
2003-01-01 04:48:01 +00:00
Tim Peters 521fc15e62 A new, and much hairier, implementation of astimezone(), building on
an idea from Guido.  This restores that the datetime implementation
never passes a datetime d to a tzinfo method unless d.tzinfo is the
tzinfo instance whose method is being called.  That in turn allows
enormous simplifications in user-written tzinfo classes (see the Python
sandbox US.py and EU.py for fully fleshed-out examples).

d.astimezone(tz) also raises ValueError now if d lands in the one hour
of the year that can't be expressed in tz (this can happen iff tz models
both standard and daylight time).  That it used to return a nonsense
result always ate at me, and it turned out that it seemed impossible to
force a consistent nonsense result under the new implementation (which
doesn't know anything about how tzinfo classes implement their methods --
it can only infer properties indirectly).  Guido doesn't like this --
expect it to change.

New tests of conversion between adjacent DST-aware timezones don't pass
yet, and are commented out.

Running the datetime tests in a loop under a debug build leaks 9
references per test run, but I don't believe the datetime code is the
cause (it didn't leak the last time I changed the C code, and the leak
is the same if I disable all the tests that invoke the only function
that changed here).  I'll pursue that next.
2002-12-31 17:36:56 +00:00
Tim Peters e39a80c362 Bite the bullet on all the indirect timetz and datetimetz tzinfo methods:
make the callers figure out the right tzinfo arguments to pass, instead of
making the callees guess.  The code is uglier this way, but it's less
brittle (when the callee guesses, the caller can get surprised).
2002-12-30 21:28:52 +00:00
Tim Peters bad8ff089a A step on the way to making tzinfo classes writable by mortals: get rid
of the timetz case.  A tzinfo method will always see a datetimetz arg,
or None, now.  In the former case, it's still possible that it will get
a datetimetz argument belonging to a different timezone.  That will get
fixed next.
2002-12-30 20:52:32 +00:00
Tim Peters 8702d5f33f And put back a little code duplication, in the form of asserts. 2002-12-27 02:26:16 +00:00
Tim Peters 00237037ae Squash recently-introduced code duplication. 2002-12-27 02:21:51 +00:00
Tim Peters 60c76e4016 Make comparison and subtraction of aware objects ignore tzinfo if the
operands have identical tzinfo members (meaning object identity -- "is").
I misunderstood the intent here, reading wrong conclusion into
conflicting clues.
2002-12-27 00:41:11 +00:00
Tim Peters 80475bb4d2 Implemented datetime.astimezone() and datetimetz.astimezone(). 2002-12-25 07:40:55 +00:00
Tim Peters 12bf339aea Implemented .replace() methods for date, datetime, datetimetz, time and
timetz.
2002-12-24 05:41:27 +00:00
Tim Peters 2736285035 call_utc_tzinfo_method(): Got rid of the label and the gotos. 2002-12-23 16:17:39 +00:00
Tim Peters d684415572 I give up: unless I write my own strftime by hand, datetime just can't
be trusted with years before 1900, so now we raise ValueError if a date or
datetime or datetimetz .strftime() method is called with a year before
1900.
2002-12-22 20:58:42 +00:00
Tim Peters 83b85f1d6c Python's strftime implementation does strange things with the year,
such that the datetime tests failed if the envar PYTHON2K was set.
This is an utter mess, and the datetime module's strftime functions
inherit it.  I suspect that, regardless of the PYTHON2K setting, and
regardless of platform limitations, the datetime strftime wrappers
will end up delivering nonsense results (or bogus exceptions) for
any year before 1900.  I should probably just refuse to accept years
earlier than that -- else we'll have to implement strftime() by hand.
2002-12-22 20:34:46 +00:00
Tim Peters 14b6941197 classify_object(): Renamed more meaningfully, to classify_utcoffset().
Also changed logic so that instances of user-defined subclasses of date,
time, and datetime are called OFFSET_NAIVE instead of OFFSET_UNKNOWN.
2002-12-22 18:10:22 +00:00
Tim Peters 855fe88b24 Implemented a Wiki suggestion:
{timetz,datetimetz}.{utcoffset,dst}() now return a timedelta (or None)
instead of an int (or None).

tzinfo.{utcoffset,dst)() can now return a timedelta (or an int, or None).

Curiously, this was much easier to do in the C implementation than in the
Python implementation (which lives in the Zope3 code tree) -- the C code
already had lots of hair to extract C ints from offset objects, and used
C ints internally.
2002-12-22 03:43:39 +00:00
Tim Peters 328fff7214 format_utcoffset(): The natural type of the buflen arg is size_t, so
used that.

wrap_strftime():  Removed the most irritating uses of buf.

TestDate.test_ordinal_conversions():  The C implementation is fast enough
that we can afford to check the endpoints of every year.  Also added
tm_yday tests at the endpoints.
2002-12-20 01:31:27 +00:00
Neal Norwitz dfb8086760 Fix another long vs int mismatch. test_datetime now passes on alpha 2002-12-19 02:30:56 +00:00
Tim Peters 0b0f41cf1f Fixed typo in string. 2002-12-19 01:44:38 +00:00
Neal Norwitz c296c63c73 Fix crash on alphas due to mismatch between 'l' format and int variables. 2002-12-19 00:42:03 +00:00
Tim Peters ba873472d2 delta_str(): Purged last uses of sprintf (in favor of PyOS_snprintf). 2002-12-18 20:19:21 +00:00
Jack Jansen 51cd8a2d24 "time_second" is apparently a #define on MacOSX. Renamed the (static)
routine to py_time_second.
2002-12-17 20:57:24 +00:00
Guido van Rossum bd43e9195b Fix GCC warnings. It turns out two out of three pointed to real bugs! 2002-12-16 20:34:55 +00:00
Tim Peters 2a799bf77a datetime escapes the sandbox. The Windows build is all set. I leave it
to others to argue about how to build it on other platforms (on Windows
it's in its own DLL).
2002-12-16 20:18:38 +00:00