Skip to content

NXT-4230: Make datetime format consistent with version panel on hub #115

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
hriverahdez merged 3 commits into from
Feb 13, 2026
Merged

NXT-4230: Make datetime format consistent with version panel on hub #115

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
05e270e
NXT-4230: Make datetime format consistent with version panel on hub
xnhp Feb 11, 2026
1f8b34d
NXT-4230: Improve date formatting method
xnhp Feb 12, 2026
82b92f0
NXT-4230: Use datetime utils from webapps-common
xnhp Feb 13, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 15 additions & 8 deletions org.knime.ui.js/src/components/workflowEditor/ChangeHubItemVersionModal.vue
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ import {
KdsModal,
KdsRadioButtonGroup,
} from "@knime/kds-components";
import { formatDateString } from "@knime/utils";
import { formatDateTimeString } from "@knime/utils";

import {
ItemVersion,
Expand Down Expand Up @@ -67,6 +67,19 @@ type DropdownOption = {

const MAX_DESCRIPTION_LENGTH = 120;

const formatCreatedOn = (createdOnValue: string | Date) => {
Copy link
Contributor

@hriverahdez hriverahdez Feb 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have many questions 😄

bottom line: dates are awkward in JS, don't understimate them

Image

Copy link
Contributor Author

@xnhp xnhp Feb 12, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the generated gateway API, NamedItemVersion.createdOn is in fact declared as a Date.

But apparently it can be declared a Date but still actually be a String at runtime since (is that correct?) typescript types really "exist" only at compile time.

The locale specification was intentional to be consistent with hub webapp but I do agree that it is awkward.

I made some improvements to the method, is that better?

We can already start defining one singular format for the frontend but not sure if its worth it right now. What do you think?

Copy link
Contributor

@hriverahdez hriverahdez Feb 12, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But apparently it can be declared a Date but still actually be a String at runtime since (is that correct?) typescript types really "exist" only at compile time.

The type is mapped as Date, but this is just a type. At runtime, the value is transfered over RPC as a date string, so this will never be a Date object

The locale specification was intentional to be consistent with hub webapp

Ah, I see

We can already start defining one singular format for the frontend but not sure if its worth it right now.

Would be a good idea. I can bring it up and we can (later) add it to WAC

Copy link
Contributor

@hriverahdez hriverahdez Feb 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, actually, there's something already in WAC
https://github.com/knime/webapps-common/blob/master/packages/utils/src/format.ts#L10

Maybe you should use that. It seems to be doing the same and to the same format

const date =
createdOnValue instanceof Date ? createdOnValue : new Date(createdOnValue);
if (Number.isNaN(date.getTime())) {
const rawValue =
createdOnValue instanceof Date ? null : createdOnValue.trim();
return rawValue ? `Created on ${rawValue}` : "Created on unknown date";
}
const dateInput =
createdOnValue instanceof Date ? date.getTime() : createdOnValue;
return `Created on ${formatDateTimeString(dateInput)}`;
};
Comment on lines 70 to 81
Copy link

Copilot AI Feb 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This mixes UTC and local time: dateLabel is derived from date.toISOString() (UTC-based), while timeLabel is formatted from the Date object in the user’s local timezone. Around midnight, this can produce inconsistent labels like a UTC date with a local time from the previous/next day. Use a single timezone basis for both (e.g., format both parts via the same Intl.DateTimeFormat with an explicit timeZone, or ensure formatDateString formats from the same Date/timezone used for the time).

Copilot uses AI. Check for mistakes.

const dropdownOptions = computed<DropdownOption[]>(() =>
itemVersions.value
.filter(
Expand All @@ -77,13 +90,7 @@ const dropdownOptions = computed<DropdownOption[]>(() =>
const title = version.title ?? "Untitled";
const author = version.author ? `Author: ${version.author}` : null;
const createdOnValue = version.createdOn;
const createdOn = createdOnValue
? `Created: ${formatDateString(
createdOnValue instanceof Date
? createdOnValue.toISOString()
: createdOnValue,
)}`
: null;
const createdOn = createdOnValue ? formatCreatedOn(createdOnValue) : null;
const rawDescription = version.description?.trim() ?? "";
let description: string | null = null;
if (rawDescription.length > 0) {
Expand Down
Loading