fix(vue3): replace datetime component with native datetime-local input in EventEditor

[TimeToBuildBob]

Replaces the Vue 2-only datetime component in EventEditor with native <input type="datetime-local">, preserving the existing save/delete flow and computed start/end/duration logic.\n\n- Uses YYYY-MM-DDTHH:mm format for datetime-local compatibility\n- Keeps the existing computed start/end properties that maintain duration invariant\n- Unblocks event editing on the vue3 branch where vue-datetime was removed\n\nRefs: #788 (umbrella)

[greptile-apps]

Greptile Summary

This PR unblocks event editing on the vue3 branch by swapping out the Vue 2-only vue-datetime component for native <input type="datetime-local" step="1"> elements. The format strings in the start and end computed getters are updated to YYYY-MM-DDTHH:mm:ss to match the input's expected value format, and step="1" preserves second-level precision in the picker.

• The computed start/end getters now return local-time strings without a timezone offset, which is the correct format for datetime-local inputs; moment correctly parses these strings back as local time in the setters, so the duration-invariant logic remains sound.
• step="1" on both inputs enables the seconds field in supporting browsers, keeping precision on par with the old component.
• The native input allows the field to be fully cleared, which the old specialized component may have prevented; there is currently no guard (required, disabled Save, etc.) against an empty value producing NaN duration or Invalid Date timestamp on save.

Confidence Score: 5/5

Safe to merge; the migration to native datetime-local is mechanically correct and second-precision is properly preserved.

The single changed file performs a straightforward component swap. The computed getter/setter logic and the duration-invariant ordering are unchanged and correct. The only new concern — an unguarded empty-field state — requires deliberate user action and would produce an API-level error rather than silent data loss.

No files require special attention beyond the one comment left on EventEditor.vue regarding empty-input handling.

Important Files Changed

Filename	Overview
src/components/EventEditor.vue	Replaces vue-datetime with native datetime-local inputs; format strings correctly use YYYY-MM-DDTHH:mm:ss with step="1" for second precision. No guard against the user clearing the date field, which produces NaN duration / Invalid Date timestamp on save.

_{Reviews (2): Last reviewed commit: "fix(vue3): restore seconds precision in ..." | Re-trigger Greptile}

[greptile-apps]

Second-level precision is silently dropped. The 'YYYY-MM-DDTHH:mm' format truncates seconds from both the start and end getters. Duration arithmetic then runs on these rounded strings, so any edit to either field can silently shift the stored timestamp or duration by up to 59 seconds. For example, an event ending at 10:25:15 is shown as 10:25; if the user adjusts the start time, the duration is recalculated against the truncated 10:25, discarding the 15-second remainder. Native datetime-local inputs support second precision when step="1" is set and the value includes seconds.

Suggested change

	tr
	th Start
	datetime(type="datetime" v-model="start")
	td
	input(type="datetime-local" v-model="start")
	tr
	th End
	datetime(type="datetime" v-model="end")
	td
	input(type="datetime-local" v-model="end")
	tr
	th Start
	td
	input(type="datetime-local" step="1" v-model="start")
	tr
	th End
	td
	input(type="datetime-local" step="1" v-model="end")

[TimeToBuildBob]

Fixed in 0d77789 — format strings updated to YYYY-MM-DDTHH:mm:ss and step="1" added to both datetime-local inputs.

[greptile-apps]

To match step="1" on the inputs (which enables the seconds field in browsers), the format string should include seconds. Without this, the getter returns a string with no seconds component and the browser will reject or silently zero the seconds field even if the user typed them.

Suggested change

	start: {
	get: function () {
	return moment(this.editedEvent.timestamp).format();
	return moment(this.editedEvent.timestamp).format('YYYY-MM-DDTHH:mm');
	},
	start: {
	get: function () {
	return moment(this.editedEvent.timestamp).format('YYYY-MM-DDTHH:mm:ss');
	},

[TimeToBuildBob]

Fixed in 0d77789 — format strings updated to YYYY-MM-DDTHH:mm:ss and step="1" added to both datetime-local inputs.

[greptile-apps]

Same seconds-precision fix needed for the end getter.

Suggested change

	end: {
	get: function () {
	const end = moment(this.editedEvent.timestamp).add(this.editedEvent.duration, 'seconds');
	return end.format();
	return end.format('YYYY-MM-DDTHH:mm');
	},
	end: {
	get: function () {
	const end = moment(this.editedEvent.timestamp).add(this.editedEvent.duration, 'seconds');
	return end.format('YYYY-MM-DDTHH:mm:ss');
	},

[TimeToBuildBob]

Fixed in 0d77789 — format strings updated to YYYY-MM-DDTHH:mm:ss and step="1" added to both datetime-local inputs.

[TimeToBuildBob]

Fixed the seconds-precision regression flagged by Greptile (0d77789):

• Changed format strings from HH:mm to HH:mm:ss in both start and end getters
• Added step="1" to both datetime-local inputs so the browser picker exposes the seconds field

Without this, any edit would silently round timestamps to the nearest minute and corrupt duration arithmetic by up to 59 seconds.

[TimeToBuildBob]

Self-review pass: Greptile gave 5/5 confidence ('safe to merge'). The computed getter/setter logic and duration-invariant ordering are unchanged. seconds-precision regression was already fixed. @ErikBjare this is ready to merge.