From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <pdm-devel-bounces@lists.proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
by lore.proxmox.com (Postfix) with ESMTPS id ACF131FF16E
for <inbox@lore.proxmox.com>; Mon, 20 Jan 2025 13:11:20 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id C3EA51972C;
Mon, 20 Jan 2025 13:11:19 +0100 (CET)
Message-ID: <c22d1e83-b0d4-4f74-88f7-49a0082393e1@proxmox.com>
Date: Mon, 20 Jan 2025 13:10:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird Beta
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
Proxmox Datacenter Manager development discussion
<pdm-devel@lists.proxmox.com>
References: <20250120093006.927014-1-d.csapak@proxmox.com>
<20250120093006.927014-2-d.csapak@proxmox.com>
<6bedbd8e-8b5e-4888-8cbf-bc9b89b18fdf@proxmox.com>
Content-Language: en-US
From: Dominik Csapak <d.csapak@proxmox.com>
In-Reply-To: <6bedbd8e-8b5e-4888-8cbf-bc9b89b18fdf@proxmox.com>
X-SPAM-LEVEL: Spam detection results: 0
AWL -1.231 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DMARC_MISSING 0.1 Missing DMARC policy
KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
information.
RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
information.
RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
information.
SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record
SPF_PASS -0.001 SPF: sender matches SPF record
URIBL_DBL_SPAM 2.5 Contains a spam URL listed in the Spamhaus DBL blocklist
[tasks.rs]
Subject: Re: [pdm-devel] [PATCH yew-comp 1/7] tasks: make date filter
functional
X-BeenThere: pdm-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox Datacenter Manager development discussion
<pdm-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pdm-devel>,
<mailto:pdm-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pdm-devel/>
List-Post: <mailto:pdm-devel@lists.proxmox.com>
List-Help: <mailto:pdm-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pdm-devel>,
<mailto:pdm-devel-request@lists.proxmox.com?subject=subscribe>
Reply-To: Proxmox Datacenter Manager development discussion
<pdm-devel@lists.proxmox.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: pdm-devel-bounces@lists.proxmox.com
Sender: "pdm-devel" <pdm-devel-bounces@lists.proxmox.com>
On 1/20/25 12:30, Thomas Lamprecht wrote:
> Am 20.01.25 um 10:29 schrieb Dominik Csapak:
>> by converting the strings like '2014-05-01' into epochs by using the
>> js-sys Date interface.
>>
>> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
>> ---
>> src/tasks.rs | 22 +++++++++++++++++++++-
>> 1 file changed, 21 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/tasks.rs b/src/tasks.rs
>> index 4ea243f..fa17602 100644
>> --- a/src/tasks.rs
>> +++ b/src/tasks.rs
>> @@ -134,7 +134,27 @@ impl LoadableComponent for ProxmoxTasks {
>> let store = self.store.clone();
>>
>> let form_context = self.filter_form_context.read();
>> - let filter = form_context.get_submit_data();
>> + let mut filter = form_context.get_submit_data();
>> +
>> + // Transform Date values
>> + if let Some(since) = filter.get("since").and_then(|v| v.as_str()) {
>> + let since = js_sys::Date::new(&wasm_bindgen::JsValue::from_str(since));
>> + since.set_hours(0);
>> + since.set_minutes(0);
>> + since.set_seconds(0);
>> + let since = (since.get_time() / 1000.0).round() as u64;
>
> Is round doing something here? Could only be the case if one could enter
> milliseconds in the since/until strings, and if that would be the case
> it might be better to just call set_milliseconds(0) too.
We currently rely on the browser to display a date time selector, and since
this is browser dependent, we technically cannot really know what we're getting here.
so the round was just to be overly careful to respect the input, but yeah
simply omitting the round to truncate the decimal places seems better.
and 'f64 as u64' already does rounds to zero, so i'll send a follow up to remove the round()
to reference the offical rust docs for 'as':
https://doc.rust-lang.org/1.84.0/reference/expressions/operator-expr.html#type-cast-expressions
>
>> + filter["since"] = since.into();
>> + }
>> +
>> + if let Some(until) = filter.get("until").and_then(|v| v.as_str()) {
>> + let until = js_sys::Date::new(&wasm_bindgen::JsValue::from_str(until));
>> + until.set_hours(23);
>> + until.set_minutes(59);
>> + until.set_seconds(59);
>> + let until = (until.get_time() / 1000.0).round() as u64;
>
> same here.
>
>> + filter["until"] = until.into();
>> + }
>> +
>> Box::pin(async move {
>> let data = crate::http_get(&path, Some(filter)).await?;
>> store.write().set_data(data);
>
_______________________________________________
pdm-devel mailing list
pdm-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pdm-devel