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

[Patrick K. O'Brien]

[Tim Peters]

> > SCREAM!!!  Returning -42137 is *not* the same as returning zero!!!
>
> Of course it isn't, and that's the point.  Up until now, you've said:
>
>     [from <http://www.zope.org/Members/fdrake/DateTimeWiki/NaiveTime>]
>     Whether a datetime object represents UTC, local time, or time in
>     some other timezone is purely up to the program; just like it's up
>     to the program whether a particular number represents meters, miles,
>     or mass.
>
> If you're now telling me that I'm not allowed to pretend a datetime object
> is 42137 seconds removed from UTC, then the nature of "naive time" has
> changed.  [Oops:  I see the defn of tzoffset() has changed to
> minutes now --
> whatever.]
>
> Or does "dt" in the example not refer to an arbitrary datetime object, but
> only to a (subclass of) datetimetz?  Even then, I should be able
> to make up
> any silly rules I want <wink>.
>
> > I'm not sure where the misunderstanding is.  Naive datetime doesn't
> > have an explicit timezone, but it could have an implied timezone that
> > the application knows.
>
> Presumably my application wants to believe a naive datetime is 42137
> sec^H^H^H minutes off from UTC.  In that case I believe my app's
> version of
> a UTC tzinfo object must return +-42137 when a naive datetime is passed to
> its tzoffset() method.
>
> > The datetimetz class is intended to make the timezone explicit.
>
> Sure.  And if I, e.g., live in a DST-free part of the world, and choose to
> believe that a naive datetime *is* my local time, then my version of a UTC
> tzinfo object is going to have to take my belief into account.
>
> An alternative (and probably saner <wink>) is to stop saying that "naive
> time" makes no assumptions, but that when combined with a tzinfo object it
> specifically assumes UTC stripped of leap seconds, and users have
> no choice
> about that.  Then your example classes are compelling.
>
> > When I create a datetimetz object, I pass in a tzinfo object that
> > represents the timezone semantics I want to use for this datetimetz
> > object.  So if I am going to record times in UTC, I pass an instance
> > (or maybe *the* instance :-) of the UTC class.
>
> If your app chooses to believe that "naive" datetimes are at an
> offset of 0
> from UTC, or the spec changes to *require* that belief when using tzinfo
> objects, fine by me.  The sample UTC class doesn't make sense
> unless that's
> what you do choose (or are forced) to believe.

Take a look at the sample tzinfo classes here:
http://www.zope.org/Members/fdrake/DateTimeWiki/TimeZoneInfo

What you seem to be arguing for sounds remarkably like the FixedOffset
class. Whereas, implied by its name and intent, the UTC class *is* meant to
an offset of 0 from UTC. But neither has anything in particular to do with
naive time, as both are allowed to be combined with a naive time in a
datetimetz object.

Your suggestion is kind of like having __str__ return something other than a
string. Its certainly possible, but defeats the purpose.

>>> class A:
...     def __str__(self):
...         return 1
...
>>> a = A()
>>> a.__str__()
1
>>>

---
Patrick K. O'Brien
Orbtech