[Zope3-dev] Can we remove ZopeLegacy for now?

[Patrick K. O'Brien]

[Tim Peters]
> I expect the docs don't mean what they appear to say, or are leaving too
> much unsaid.  "That date and time" doesn't *mean* anything concrete unless
> you tell me the time system it's measured in.
>
>     now = datetime(2002, 3, 15, 21, 16)
>
> is a specific datetime object, and UTC().tzoffset(now) is not at
> all telling
> me now's "timezone offset in seconds east of UTC" unless I assume now is a
> UTC time to begin with.  Is that clearer?  I'm not arguing
> anything "in the
> abstract", I'm trying to figure out what the existing words *mean*.

Yes, that is clearer. (And I realize your "arguments" were only in jest.) I
think what is confusing is that (I think) a tzinfo object is only
meaningfully useable in the context of a given datetimetz. (I'm assuming
this is what Guido intends.) So even though a tzinfo has methods that take a
dt argument, I think what is implied is the the dt argument would never be
anything other than the datetimetz instance that also held the tzinfo
instance in question. (I hope that makes sense.) So to put a tzinfo object
in a datetimetz instance (as part of the init) is to specificy that there is
a relationship between the tzinfo instance and the "underlying" naive
datetime. Presumably the application that creates these datetimetz instances
would have the logic (and responsibility) for associating naive datetimes
with the "right" tzinfos. (If datetimetz were a container that held one
naive datetime and one tzinfo, rather than a subclass of datetime, that
would be closer to how I conceptualize the relationship between these
things.)

> Perhaps it's trying to say that a tzinfo *specifies*, rather than reveals,

That is how I interpret the example code. (But I had to read it a few times
to come to my current understanding, which may still be flawed relative to
what Guido really has in mind.)

> the tzoffset corresponding to a given datetime.  That even appears likely
> now.  But even in that case, it's unclear why the sample classes ignore
> whatever tzinfo object may be attached to their dt argument if dt is a
> datetimetz instance.

I had assumed that the dt argument would be supplied by the datetimetz
object that held the tzinfo instance, and could therefore be ignored. (See
my sample code below.) Other messages have suggested some kind of conversion
could take place. The semantics of all this definitely need to be worked
out. I think we are all confused a bit by the partial implementation.

> I'm afraid this just isn't going to make sense to me until I see concrete
> examples of intended use.

I agree. Here is how I picture the datetimetz class. I'm sure Guido will
yell if I'm way off base with this.

class datetimetz(datetime):
    """A subclass of datetime that adds an optional timezone info object.
    If the tzinfo object is None, this behaves identical to naive
datetime."""

    def __init__(dtstuff, tzinfo=None):
        # Greatly simplified -- for illustration purposes only.
        super(datetimetz, self).__init__(dtstuff)
        self.tzinfo = tzinfo

    def tzoffset(self):
    "Return the offset east of UTC, in minutes"
        if tzinfo is None: raise AttributeError
        return self.tzinfo.tzoffset(dt=self)

    def tzname(self):
    "Return a string that names the intended timezone"
        if tzinfo is None: raise AttributeError
        return self.tzinfo.tzname(dt=self)

    def tzdst(self):
    "Return 0 if DST is not in effect, or the DST offset if DST is in
effect"
        if tzinfo is None: raise AttributeError
        return self.tzinfo.tzdst(dt=self)

    def tzinfo(self):
    "Return the tzinfo object"
        return self.tzinfo

With this approach, I don't see anyone accessing a tzinfo's methods
directly, only indirectly through a datetimetz instance.

> > Your suggestion ...
>
> What is the suggestion you believe I made?  The only one I believe I made
> was that we become explicit about assumptions.

I only meant your suggestion that you should be "allowed to pretend a
datetime object is 42137 seconds removed from UTC." Which I realize you put
forth in an attempt to "become explicit about assumptions".

---
Patrick K. O'Brien
Orbtech