[DB-SIG] DateTime: Changing the time value handling ?!

Greg Stein (Exchange) gstein@exchange.microsoft.com
Wed, 11 Mar 1998 03:04:43 -0800


Why should Unix ticks be any different from the others? All of the times are
absolute with respect to an unknown time zone. You have NOT picked any time
zone. If you generate a ticks value, then somebody should use that with
respect to the proper time zone.

Generally, the only point where a time zone becomes apparent is when people
use something like the .Format() method (or time.ctime()) and the output
includes a time zone string.

It sounds like people are mixing time zones values. e.g. they create a
DateTime assuming it is within the current time zone, but then pass it to a
function in the time module that expects a UTC time (or vice versa).

A large part of the discussion has historically fallen around time zone
handling. The unofficial consensus has always come out of that with "don't
build time zone information into the base types" (let higher levels deal
with it)

I would highly recommend the absolute avoidance of anything that infers /
implies time zones within the base data types.

-g

-----Original Message-----
From:	M.-A. Lemburg [SMTP:lemburg@uni-duesseldorf.de]
Sent:	Friday, March 06, 1998 4:42 AM
To:	Python Mainlist @ Python.Org
Cc:	DB-SIG @ Python.org
Subject:	[DB-SIG] DateTime: Changing the time value handling ?!

For infos on DateTime, two types for date and time handling
written in C, see:
	http://starship.skyport.net/~lemburg/mxDateTime.html

Upon common request I am planning to change the behaviour
of handling conversion from and to Unix ticks.

It currently converts Unix ticks (the floats that time.time() returns)
to UTC (aka GMT) for the broken down time representation
(giving an output similar to time.gmtime()). Conversion from
a DateTime instance to a ticks float is also done assuming
the stored value being given in UTC (something like time.mktime
for UTC values).

Several users have complained about this not being very
intuitive, so I'm considering adding new ways to do the conversion,
e.g. provide a DateTimeFromLocalTime(1234.567) constructor
and a .localtime() method. Conversion to a float will also
use local time.

Is that ok with you ?

-- 
Marc-Andre Lemburg



_______________
DB-SIG  - SIG on Tabular Databases in Python

send messages to: db-sig@python.org
administrivia to: db-sig-request@python.org
_______________

_______________
DB-SIG  - SIG on Tabular Databases in Python

send messages to: db-sig@python.org
administrivia to: db-sig-request@python.org
_______________