>
> I really can't quite fathom why you'd want to use something so low-level as
>> time.mktime... or just about anything in the time module :)
>>
> I didn't know anything better,
> but (forgive me if I'm wrong) I find mx almost as low-level :
> >>> mx.DateTime.strptime('01-01-53',"%d-%m-%y")
> <mx.DateTime.DateTime object for '2053-01-01 00:00:00.00' at 1cddc60>
> while all we human know ..
>
> I agree it's better not to work with string dates, but that's the way how
> we human write things down ;-)
> So I must use at least something like strptime.
>
mx.DateTime provides all the low-level tools if you must use them of course,
but it has high level tools too.
>>> mx.DateTime.Parser.DateFromString("01-01-1953")
<mx.DateTime.DateTime object for '1953-01-01 00:00:00.00' at 6211e0>
Now if you're storing your years as 2-digits, yeah, it'll run into trouble
and you'll have to deal with issues related to that manually. It can't know
by default if you mean 01-01-53 as someone's birthdate in 1953, or some
future event in 2053.
It also parses the common "standardized" date representations (and faster if
its a known format, as mx.DateTime.Parser has to guess at the format until
it finds one that matches/works)-- ISO 8601 and the ARPA formats, for
example. The mx.DateTime.ISO and mx.DateTime.ARPA modules are for that.
Personally, while /users/ may write a date in a lazy way like "01-01-53",
I'd never store that and would avoid having them enter them directly. At the
UI level I'd validate and normalize it to a standard format before storing
it.
E.g. instead of users entering someone's birthday into a control, I'd use a
calendar control, and store it with (in wx terms) date.FormatISODate(). Or
use date.toString(ISODate) in QT terms (ish).
I might not display it in ISO format, but.. storing it in a standard format
makes processing easier. Faster to import into mx.DateTime, and then I just
display it as dt.Format("%x") so they see a date like they expect.
HTH,
--S
--
http://mail.python.org/mailman/listinfo/python-list
