[Python-bugs-list] [ python-Bugs-660872 ] datetimetz constructors behave counterintuitively (2.3a1)

[noreply@sourceforge.net]

Bugs item #660872, was opened at 2003-01-02 00:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660872&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Nobody/Anonymous (nobody)
Summary: datetimetz constructors behave counterintuitively (2.3a1)

Initial Comment:
datetimetz.fromtimestamp(timestamp,tzinfo) creates a
datetime which has the localtime() value of timestamp,
with the tzinfo attached as its timezone.  But this
produces a counterintuitive result.  Instead of getting
the UTC time represented by timestamp, converted to the
tzinfo timezone, one only ends up with a correct value
if tzinfo is a perfect match for whatever 'localtime'
is.  This seems useless as well as counterintuitive,
since one must therefore do this:

datetimetz.fromtimestamp(stamp,localtime_tz).astimezone(tzinfo)

to get what's desired.  Or, one can do:

datetimetz.utcfromtimestamp(stamp).replace(tzinfo=utc).astimezone(tzinfo)

Both of these seem unreasonably complex ways of doing
something simple: render this UTC timestamp as a
datetime in a specified timezone.

Similarly, I would expect datetimetz.now(tzinfo) to
return the current time in the zone specified by
tzinfo, but again this is not what it does.  Similarly,
you must do:

datetimetz.now(localtime_tz).astimezone(tzinfo)

or:

datetimetz.utcnow().replace(tzinfo=utc).astimezone(tzinfo)

to get the current time in the zone specified by
tzinfo. Given that these constructors *know* what the
UTC time is, why don't they behave more meaningfully? 
It seems to me that finding the current time in a
timezone, or rendering a timestamp as it would be seen
in a timezone, are common enough use cases, but I
cannot think of any use cases for what the constructors
actually do instead.


----------------------------------------------------------------------

>Comment By: Phillip J. Eby (pje)
Date: 2003-01-02 03:40

Message:
Logged In: YES 
user_id=56214

But in your use case, if the timezone they attach is in fact
equivalent to localtime, then the conversion would be a
no-op anyway, right?  So how would a conversion in the
general case be wrong?

At the very least, this is a documentation bug.  If these
constructors only produce meaningful results for a tzinfo
that's exactly equivalent to the system's localtime(), then
the docs should say so.  Otherwise, someone can write code
that appears to work, for example, on their own machine, and
then fails when run on a machine with a different concept of
localtime().

Now, if you can actually come up with a sensible use case
for *wrongly* translating a UTC-based timestamp to a
particular timezone, with the degree of wrongness depending
on the difference between localtime() and the specified
timezone, that might justify the constructor behavior.  :) 
As it is, I find it hard to believe that whatever you come
up with will be a more common need than rendering a UTC
timestamp as a datetime value in a specified timezone.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-02 01:14

Message:
Logged In: YES 
user_id=31435

I always figured the use case for fromtimestamp(stamp, tz) 
was indeed so the user had a dead-easy way to attach 
their own local time tzinfo class to a timestamp, and that's 
all.  I would find the behavior you describe counterintuitive 
instead:  if I want a conversion, I'd rather ask for one 
explicitly (via astimezone()).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660872&group_id=5470