On Tue, 5 Mar 2002, M.-A. Lemburg wrote:
> > [Tim]
> > > The only conclusion I have at this time is that I like datetime
> > > objects better than real life <wink>.
> > [Guido]
> > Depends on how you look. If you look at the hour attribute, or call
> > the isoformat() method, or use str(), you'll see 3pm. If you ask the
> > ctime() or timetuple() methods, it converts to local time, and you'll
> > see 2pm or 4pm!
> [MAL]
> You should forget about DST if you want a sane
> implementation. Same for leap seconds.
My datetime objects manage these complexities by layering their
implementation. Our base class stores a time since epoch and a timezone
offset. It implements all the arithmetic functions based on 1day=24hours
and has methods that re-normalize the timezone to a fixed offset after every
modifying operation. It also has a translate(tzoffset) function that
returns the an adjusted time since epoch with a different timezone offset.
This way, our client applications _never_ deal with DST or timezone changes
unless they request it.
For calculations that require DST awareness, of which there are a surprising
number, we have a datetime sub-class that adds two extra modes:
1) Fixed tzoffset (from base datetime)
2) Fixed tzoffset +/- fixed DST adjustment based on current time since
epoch (folds in to case 1 after initialization)
3) Fixed tzoffset +/- dynamic DST based on stored time since epoch
(dynamically updates after every mutating date operation)
> If someone wants DST and timezone aware time differences,
> then this is a completely different concept than taking the
> difference w/r to number of days.
Precisely. Our implementation is sub-optimal in that it can do roughly
twice as much work as necessary at times. This is because we layer the DST
adjustments on top of the datetime object. The advantage to this approach
is that the code is very cleanly segregated between DST agnostic code and
DST pathological code.
> Just to hint at another problem: you sometimes want to
> know the time difference of two dates in terms of
> years, months, days, hours, etc. that is, you are not
> interested in 86400 second days, but in calendar days
> or even months. For months you'll run into problems
> with non-existing days, e.g. for 2002-03-31 - 1 month.
We handle these cases with a business logic layer on top of the DST aware
datetime object. It handles exceptions thrown, like BeyondEndOfMonthError,
and takes the appropriate action. In the case of BeyondEndOfMonthError, the
typical resolution is to set the day to the last day of the month.
-Kevin
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com
Fax: (216) 986-0714 WWW: http://www.theopalgroup.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4