[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Guu, Jin-Cheng
Subject: Re: Shorter and more flexible implementation for parse-time.el
Date: Sun, 25 Jul 2021 04:38:06 -0500

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]