time, calendar, datetime, etc

[Ben S]

Skip Montanaro wrote:
>     kylotan> Is there any chance of these modules becoming somewhat
>     combined kylotan> in the future?
>
> Maybe.  Perhaps you would like to write a PEP?

I would think that is best left up to those who know what they're
doing... I'm just a newbie who's found date and time handling in Python
to be confusing, and thought I'd mention it. (And I am the original
poster, btw.)  If nobody else agrees, maybe it's not really a problem.

>     kylotan> Right now it seems a little awkward to find the function
>     you kylotan> want. The main culprit is 'timegm' which is the only
>     thing I kylotan> need from the calendar module but which should
>     probably be in kylotan> the time module.
>
> I've never used it, but it looks like you're right.  It's the GMT/UTC
> equivalent of time.mktime(), right?

Possibly... I am not intimately familiar with all the different
functions. It would help if there was some sort of table in the docs
that laid the various time functions side by side for an easy
comparison.

>     kylotan> PS. I use 'time.strptime(myTime, '%a %b %d %H:%M:%S
>     %Y')' as a kylotan> reverse-asctime(), and was surprised that I
>     couldn't find this kylotan> wrapped in a function in any of the
>     modules. Maybe such a kylotan> function would be considered for
> future addition?
>
> Seems simple enough to not be needed.  What makes asctime() all that
> special?

Well, one could say that its very existence makes it special.
Technically asctime() is redundant as you can achieve the same effect
with time.strftime(). Yet it's in the library. Since time.asctime()
exists as a special case, we're assuming that the use of that particular
string format has some intrinsic merit. In particular, a lot of programs
written in C may use it for logfiles. Therefore it makes sense (to me)
to implement the inverse ("timeasc"?).

--
Ben Sizer
http://pages.eidosnet.co.uk/kylotan