public inbox for pbs-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox Backup Server development discussion
	<pbs-devel@lists.proxmox.com>,
	Dominik Csapak <d.csapak@proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox] time: make RFC3339 format in wasm conform to usual format
Date: Mon, 28 Aug 2023 13:30:26 +0200	[thread overview]
Message-ID: <a6ec4c02-bca2-4992-8b61-6d086f3e8b7e@proxmox.com> (raw)
In-Reply-To: <20230824141100.3690333-1-d.csapak@proxmox.com>

Am 24/08/2023 um 16:11 schrieb Dominik Csapak:
> on other targets we print the timestamp without fractional seconds

albeit I quite often like to know the millisecond difference between, e.g.,
log messages, but that's another topic and I definitively agree that it's
good to output the same for both.

> ('.xxxZ'), so we should remove that too on wasm

would be relative simple and good to add a unit test for this, could you please
do so?

> 
> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
> ---
>  proxmox-time/src/wasm.rs | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/proxmox-time/src/wasm.rs b/proxmox-time/src/wasm.rs
> index 04cea7d..59c26e2 100644
> --- a/proxmox-time/src/wasm.rs
> +++ b/proxmox-time/src/wasm.rs
> @@ -14,10 +14,19 @@ pub fn epoch_f64() -> f64 {
>  pub fn epoch_to_rfc3339_utc(epoch: i64) -> Result<String, Error> {
>      let js_date = js_sys::Date::new_0();
>      js_date.set_time((epoch as f64) * 1000.0);
> -    js_date
> +    let mut js_date = js_date
>          .to_iso_string()
>          .as_string()
> -        .ok_or_else(|| format_err!("to_iso_string did not return a string"))
> +        .ok_or_else(|| format_err!("to_iso_string did not return a string"))?;
> +    let len = js_date.len();
> +    if len < 24 {
> +        bail!("invalid rfc3339 string");
> +    }
> +
> +    // replace .xxxZ with Z
> +    js_date.replace_range((len - 5).., "Z");
> +
> +    Ok(js_date)

Hmm, deep in the nitpick territory, but the following (untested) seems slightly
nicer, shows the actual length in the error message when asserting that it got the
minimum length and matches make reasoning often (here: very) slightly easier.

match js_date.len() {
    len if len < 24 => bail!("invalid length {len} for rfc3339 string"),
    len => {
        js_date.replace_range((len - 5).., "Z"); // replace .xxxZ with Z
        Ok(js_date)
    }
}

>  }
>  
>  /// Convert Unix epoch into RFC3339 local time with TZ





      reply	other threads:[~2023-08-28 11:30 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-24 14:11 Dominik Csapak
2023-08-28 11:30 ` Thomas Lamprecht [this message]

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=a6ec4c02-bca2-4992-8b61-6d086f3e8b7e@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=d.csapak@proxmox.com \
    --cc=pbs-devel@lists.proxmox.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal