summaryrefslogtreecommitdiffstats
path: root/Lib/test/test_datetime.py
Commit message (Collapse)AuthorAgeFilesLines
...
* The failure of the last-second addition to the timezone coversion test isTim Peters2003-01-011-4/+12
| | | | | | understood now: it can't work. Added comments explaining why (it's "the usual"-- unrepresentable hours in local time --but in a slightly different guise).
* A new, and much hairier, implementation of astimezone(), building onTim Peters2002-12-311-86/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* A step on the way to making tzinfo classes writable by mortals: get ridTim Peters2002-12-301-17/+38
| | | | | | | 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.
* Added tests that conversion to our own timezone is always an identity,Tim Peters2002-12-301-0/+13
| | | | | and that conversion to "timezone" None is the same as stripping the tzinfo member.
* Beefed up the timezone conversion test by adding a phony UTC zone that'sTim Peters2002-12-301-67/+81
| | | | | west of the US zones getting converted, and also by using Eastern "as if" it were UTC (wrt Pacific), and vice versa.
* A start at non-trivial (== DST-aware) tests of timezone conversion.Tim Peters2002-12-291-0/+152
| | | | | | | Guido has in mind an easier way for users to code this stuff, but the only tests we have now are for fixed-offset tzinfo classes, and this stuff is extremely delicate in the endcases (read the new test code for why: there are holes in time <wink>).
* Make comparison and subtraction of aware objects ignore tzinfo if theTim Peters2002-12-271-8/+86
| | | | | | operands have identical tzinfo members (meaning object identity -- "is"). I misunderstood the intent here, reading wrong conclusion into conflicting clues.
* Added tests to ensure that timetz comparison, and datetimetzTim Peters2002-12-261-9/+67
| | | | | | | | | | | subtraction, work as documented. In the Python implementation, they weren't calling utcoffset() if both operands had the same tzinfo object. That's fine if it so happens that the shared tzinfo object returns a fixed offset (independent of operand), but can give wrong results if that's not so, and the latter obtains in a tzinfo subclass instance trying to model both standard and daylight times. The C implementation was already doing this "correctly", so we're just adding tests to verify it.
* Implemented datetime.astimezone() and datetimetz.astimezone().Tim Peters2002-12-251-0/+53
|
* Whitespace normalization.Tim Peters2002-12-241-1/+1
|
* Implemented .replace() methods for date, datetime, datetimetz, time andTim Peters2002-12-241-0/+150
| | | | timetz.
* I give up: unless I write my own strftime by hand, datetime just can'tTim Peters2002-12-221-0/+6
| | | | | | 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.
* Implemented a Wiki suggestion:Tim Peters2002-12-221-71/+118
| | | | | | | | | | | | {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.
* Added test to ensure that non-string result from dst() raises TypeError.Tim Peters2002-12-211-0/+6
|
* Changes sufficient so that pickles written by the Python implementationTim Peters2002-12-211-9/+15
| | | | can be read by the C implementation. I don't really understand this.
* format_utcoffset(): The natural type of the buflen arg is size_t, soTim Peters2002-12-201-9/+16
| | | | | | | | | | 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.
* Made this a little more compatible w/ the sandbox version, which isTim Peters2002-12-161-2/+2
| | | | still needed to test the Python implementatino.
* datetime escapes the sandbox. The Windows build is all set. I leave itTim Peters2002-12-161-0/+2128
to others to argue about how to build it on other platforms (on Windows it's in its own DLL).
generated by cgit v0.12 at 2025-04-13 10:23:42 (GMT)