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

[M.-A. Lemburg]

Greg Stein (Exchange) wrote:
> 
> 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).

I would like to keep it the way it is as much as you do, but there
is a problem with the C lib that makes the change necessary: conversion
from a broken down time value given in UTC to a ticks value is not
supported (a few OSes define timegm() for this). I can only convert
from broken down values in local time to ticks using mktime() [the
time module exposes the same flaw, BTW]. In previous versions I simply
took that value and subtracted the timezone offset, but that fails
whenever DST is active and it also forced me to copy code from the
time module, which I can now avoid (gains some portablility and reduces
maintenance overhead).

Conversion from ticks to broken time is no problem. I use gmtime()
and localtime() for those.

> 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'm not building time zone *information* into the base type -- I only
need to make an assumption for Unix ticks since the C lib API is missing.

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

Me too, but I currently don't see any alternative. It's only the
conversion DateTime -> ticks that relies on the 'local time assumption'.
Everything else is done in a time zone independant fashion.

If you know a way around this, I'd be the first to implement it.

-- 
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
_______________