Re: Shorter and more flexible implementation for parse-time.el

[Guu, Jin-Cheng]

Thanks for sharing your food for thought!

If a project wants to use a fixed format with fixed length for each
entry, I believe that short function is useful. I do not know if this
is often wanted by others, but for me I constantly run into this
question. If there's no need, I won't push too. Just want to offer
some help :)

So yeah, my library won't deal with "3-NOV-94", but it can deal with
"03-NOV-94" or even "003-NOV-94" if the user decides to fix the format
to be "dd-mmm-YY" or "0dd-mmm-YY".

And you're totally right, date parsing as a whole won't be easy. In
general we would hope for a parser that is smart enough to deal with
flexible formats. However, some specification needs to be given at
some point - for example "01/01/01". That is why I came up with an
assumption that I think is general enough but also can have a definite
output.

Cheers,
Jin