All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] support/download/svn: fix date format for archive creation
Date: Mon, 22 Feb 2021 19:28:01 +0100	[thread overview]
Message-ID: <20210222182801.GD2276@scaer> (raw)
In-Reply-To: <4cba7ba3-06c7-b45b-81c8-4746bcee2bcf@mind.be>

Arnout, All,

On 2021-02-22 11:58 +0100, Arnout Vandecappelle spake thusly:
> On 20/02/2021 10:51, Yann E. MORIN wrote:
> > On 2021-02-19 15:21 -0600, Vincent Fazio spake thusly:
> >> Now the returned date is massaged to drop the sub-seconds.
[--SNIP--]
> A much simpler solution is
> date="$( date -d "${date}" -u +%Y-%m-%dT%T%:z )"
> which is fully portable over any POSIX-compliant version of date.

%:z is not POSIX, it's a GNU extension. However, we do not care about
computing the timezone: it's forcibly +00:00 becasue we do request -u.

Also, %T is OK, but to keep in line with the %Y-%m-%d part, I've
switched to %H:%M:%S.

Eventually, I've settled for: 

> > But I wonder whether this should be svn-specific, or whether we should
> > move it into the generic herlper mk_tar_gz()... Arnout, thoughts?
>  I would expect any sane VCS to be able to show the last change date in ISO 8601
> format - I'd hope that SVN is the exception rather than the rule...

Actually, sub-second precision *is* allowed by ISO8601. ISO8601 even
allows fractional parts after the last time element, eg.: 14:30,5 to
represent 14 hours, 30.5 minutes (i.e. 30min and 30s). The precision of
the fractional part is even left unspecified, with parties agreeing in
advance (or autodetectig, I'd guess):

    https://en.wikipedia.org/wiki/ISO_8601#Times

So, svn *is* ISO8601-compliant.

Regards,
Yann E. MORIN.

>  Regards,
>  Arnout
> 
> > 
> > Regards,
> > Yann E. MORIN.
> > 
> >>  # Generate the archive.
> >>  # We did a 'svn export' above, so it's not a working copy (there is no .svn
> >>  # directory or file to ignore).
> >> -- 
> >> 2.30.0
> >>
> > 

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

  reply	other threads:[~2021-02-22 18:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-19 21:21 [Buildroot] [PATCH] support/download/svn: fix date format for archive creation Vincent Fazio
2021-02-20  9:51 ` Yann E. MORIN
2021-02-22 10:58   ` Arnout Vandecappelle
2021-02-22 18:28     ` Yann E. MORIN [this message]
2021-02-22 20:14       ` Yann E. MORIN
2021-02-22 22:06 ` Yann E. MORIN

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210222182801.GD2276@scaer \
    --to=yann.morin.1998@free.fr \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.