From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Guu, Jin-Cheng" Newsgroups: gmane.emacs.devel Subject: Re: Shorter and more flexible implementation for parse-time.el Date: Sat, 24 Jul 2021 10:03:40 -0500 Message-ID: References: <87mtqb3o7q.fsf@gnus.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000016b9f05c7dfd46d" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17419"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jul 24 17:04:43 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m7JCk-0004Ht-IH for ged-emacs-devel@m.gmane-mx.org; Sat, 24 Jul 2021 17:04:42 +0200 Original-Received: from localhost ([::1]:36042 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m7JCj-000446-6U for ged-emacs-devel@m.gmane-mx.org; Sat, 24 Jul 2021 11:04:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46282) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m7JC0-0003Jx-0s for emacs-devel@gnu.org; Sat, 24 Jul 2021 11:03:56 -0400 Original-Received: from mail-ed1-x52a.google.com ([2a00:1450:4864:20::52a]:46655) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m7JBx-0000cF-NR for emacs-devel@gnu.org; Sat, 24 Jul 2021 11:03:55 -0400 Original-Received: by mail-ed1-x52a.google.com with SMTP id f13so2714174edq.13 for ; Sat, 24 Jul 2021 08:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EuKnNVNWdym7dlLAhOvN69m49vIYebQd0VF+IsPUmXA=; b=Xmsiwols39RGp0zfYg40lezx8K4WFxnAZpQ0AOO40RphGYWdzh6AAtwJX69p+2DF8M rhXAMOHWoMVma7FHX9jsCexKL2H1s/ewAesqTM2HXZG03O5mSbKcBPQzwYys/jgQye6c 78CEkoRg/kMtwoxY/b6PDDdVCadgWDfSrovD99jVDmTo8J7YyLyG76OI7FhYxwvKQ5T7 FfGNJlG0bclg9qHlV/tB03ThTfDFDj70Ck8RQQIvCM6zXw2sX4JO8ZTqwQzKYTpkcXDg ORVpmfUL4xrTeT5QdUuW28zHpRnptWXbIgnhNAzH+W18ZXojxaRhEdtvEu5Ln/Mm3JjX S7+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EuKnNVNWdym7dlLAhOvN69m49vIYebQd0VF+IsPUmXA=; b=ieljmKocGSpN2d+NzYBPAFQ9HHdHECl5eMGdosLdBuLQxeigis9nF9fTn6OFnw8iDt 9+s2cvqvLa1z1gHpvRZsjjnvzxQM5LXZGwIXj4Ezv8WaHSWt7QLkRVw2jydliOk2OmGu l6nqxytcChINoxPsQOBAxu8y2CqQs+T+WjMQLK7UtjhnHOEHrAITSS7JEt9mg3AkoR3a +iDEZG967iDVaz2OrnmUtUxJe8NYIPwfSdGSHL3o5q7WE60vHezik/aaNvTZ4eoEG+dM o/t0bVZ0j7zDEzRJtzzptWy5og3r/IbH5VySCkxf/PHRIe1J2SB1YzSNOSsqNB9b5cQO bBCA== X-Gm-Message-State: AOAM531R+qE86Uf3VKhe9DkmjgZK3FCP4usRlsjSt6RuPM1Uu0zWS3c4 e+EolwxJpoMNQCA3dsBVyrB7DyUWS5D9Pzty8L4= X-Google-Smtp-Source: ABdhPJzh+H1b6kpZZRUpMLhy3HAH6gHwqLg1tFPmXIvxoTYLRT+NuGmO6IvlZt6tBOC50O4O8UMuv/pZ4oT2LU8i0rI= X-Received: by 2002:a05:6402:312e:: with SMTP id dd14mr11548493edb.33.1627139032049; Sat, 24 Jul 2021 08:03:52 -0700 (PDT) In-Reply-To: <87mtqb3o7q.fsf@gnus.org> Received-SPF: pass client-ip=2a00:1450:4864:20::52a; envelope-from=jcguu95@gmail.com; helo=mail-ed1-x52a.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:271546 Archived-At: --000000000000016b9f05c7dfd46d Content-Type: text/plain; charset="UTF-8" Hi Lars, Thanks for your response! I've done some research, and the formats I have seen all have their rigid formats (with a fixed length in particular) [1][2][3]. Would you mind pointing me to some exceptions? I can try to accommodate. That said, I'd argue it is still useful. It is much shorter, is flexible and customizable, and uses lisp sexprs instead of a DSL. Please feel free to let me know what it lacks of, I will try to work on it and present a final result. =) Cheers, Jin [1] https://common-lisp.net/project/local-time/manual.html#Parsing-and-Formatting [2] https://en.wikipedia.org/wiki/ISO_8601 [3] https://www.ibm.com/docs/en/spss-statistics/23.0.0?topic=formats-date-time On Sat, Jul 24, 2021 at 7:12 AM Lars Ingebrigtsen wrote: > "Guu, Jin-Cheng" writes: > > > Currently, the built-in time parsing functions only allow us to parse > > timestrings with respect to some given formats (ISO-8601, RFC-822) > > [1]. I have a parsing function that allows users to parse with > > customized formats which are easy to write. The end result is: > > > > ``` emacs-lisp > > (my/parse-time "20200718-201504" > > '((:year 4) (:month 2) (:day 2) "-" > > (:hour 2) (:minute 2) (:second 2))) > > ;; => ((:second . 4) (:minute . 15) (:hour . 20) > > ;; (:day . 18) (:month . 7) (:year . 2020)) > > ``` > > It's an interesting approach, but in my experience (having written > parsers for probably more than a hundred different time formats), this > doesn't really get you very far -- the formats often vary in length, use > month names, and so on, so you end up having to write tiny functions for > every format. > > So I'm not sure having something like this in Emacs would help that much. > > -- > (domestic pets only, the antidote for overdose, milk.) > bloggy blog: http://lars.ingebrigtsen.no > --000000000000016b9f05c7dfd46d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Lars,

Thanks for your response! I've done some rese= arch, and the formats I have seen all have their rigid formats (with a fixe= d length in particular) [1][2][3]. Would=C2=A0you mind pointing me to some = exceptions? I can try to accommodate.=C2=A0

That said, I'd argue i= t is still useful. It is much shorter, is flexible and customizable, and us= es lisp sexprs instead of a DSL. Please feel free to let me know what it la= cks of, I will try to work on it and present a final result. =3D)

Chee= rs,
Jin

[1]=C2=A0https://common-lisp.= net/project/local-time/manual.html#Parsing-and-Formatting
[3]=C2=A0h= ttps://www.ibm.com/docs/en/spss-statistics/23.0.0?topic=3Dformats-date-time=

On Sat, Jul 24, 2021 at 7:12 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:
<= /div>
"Guu, Jin-Cheng= " <jcguu95@g= mail.com> writes:

> Currently, the built-in time parsing functions only allow us to parse<= br> > timestrings with respect to some given formats (ISO-8601, RFC-822)
> [1]. I have a parsing function that allows users to parse with
> customized formats which are easy to write. The end result is:
>
> ``` emacs-lisp
> (my/parse-time "20200718-201504"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 '((:year 4)= (:month 2) (:day 2) "-"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (:hour 2= ) (:minute 2) (:second 2)))
> ;; =3D> ((:second . 4) (:minute . 15) (:hour . 20)
> ;;=C2=A0 =C2=A0 =C2=A0(:day . 18) (:month . 7) (:year . 2020))
> ```

It's an interesting approach, but in my experience (having written
parsers for probably more than a hundred different time formats), this
doesn't really get you very far -- the formats often vary in length, us= e
month names, and so on, so you end up having to write tiny functions for every format.

So I'm not sure having something like this in Emacs would help that muc= h.

--
(domestic pets only, the antidote for overdose, milk.)
=C2=A0 =C2=A0bloggy blog: http://lars.ingebrigtsen.no
--000000000000016b9f05c7dfd46d--