[Anders J. Munch]
> If ctime/mtime/atime were to return datetime objects, that would
> pretty much have to be UTC to not lose information in the DST
> transition. I doubt that's what Walter wanted though, as that would
> leave users with the job of converting from UTC datetime to local
> datetime;
> From: Guido van Rossum [mailto:[EMAIL PROTECTED]
>
> >>> datetime.datetime.utcfromtimestamp(time.time()) -
> >>> datetime.datetime.utcnow()
> datetime.timedelta(0)
I overlooked the utcfromtimestamp method, sorry.
> Your bug is similar to comparing centimeters to inches, or speed to
> accelera
[Anders J. Munch]
> > > Alas datetime objects do not unambiguously identify a point in time.
> > > datetime objects are not timestamps: They represent the related but
> > > different concept of _local time_, which can be good for
> > presentation,
> > > but shouldn't be allowed anywhere near a pers
> I wrote:
>
> > Alas datetime objects do not unambiguously identify a point in time.
> > datetime objects are not timestamps: They represent the related but
> > different concept of _local time_, which can be good for
> presentation,
> > but shouldn't be allowed anywhere near a persistent store.
On 6/28/05, Anders J. Munch <[EMAIL PROTECTED]> wrote:
> Alas datetime objects do not unambiguously identify a point in time.
> datetime objects are not timestamps: They represent the related but
> different concept of _local time_, which can be good for presentation,
> but shouldn't be allowed an
Walter Dörwald wrote:
>
> We should have one uniform way of representing time in Python. IMHO
> datetime objects are the natural choice.
Alas datetime objects do not unambiguously identify a point in time.
datetime objects are not timestamps: They represent the related but
different concept of
[Reinhold Birkenfeld]
One more issue is open: the one of naming. As "path" is already
the name of a module, what would the new object be called to
avoid confusion? pathobj? objpath? Path?
[Michael Hoffman]
>>> I would argue for Path.
[Tony Meyer
>> Granted "path" is actually os.pa
At 12:08 PM 6/27/2005 +1200, Tony Meyer wrote:
>[Reinhold Birkenfeld]
> >> One more issue is open: the one of naming. As "path" is already the
> >> name of a module, what would the new object be called to avoid
> >> confusion? pathobj? objpath? Path?
>
>[Michael Hoffman]
> > I would argue for Path
[Reinhold Birkenfeld]
>> One more issue is open: the one of naming. As "path" is already the
>> name of a module, what would the new object be called to avoid
>> confusion? pathobj? objpath? Path?
[Michael Hoffman]
> I would argue for Path.
Granted "path" is actually os.path, but I don't think
