From f6bd306d6d6976349abdd8095c109b7011e0e803 Mon Sep 17 00:00:00 2001 From: zhangwenjian Date: Sat, 19 Sep 2026 20:50:13 +0800 Subject: [PATCH] =?UTF-8?q?fix=F0=9F=90=9B:=20send=20datetime=20fields=20a?= =?UTF-8?q?s=20RFC3339,=20not=20space-separated=20local=20time?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Both date-pickers -- the search filter and the insert/edit form -- used value-format="YYYY-MM-DD HH:mm:ss", which formats a picked instant as e.g. "2026-09-19 12:30:00": no T separator, no offset. dto.go.template declares every datetime column's InsertReq/UpdateReq field as time.Time with a plain `json:"..."` tag (R6 leaves that file alone, so there is no time_format tag to reach for instead), and encoding/json's default (Un)MarshalJSON for time.Time only accepts RFC3339. The generated form would submit new and edited datetime values in a shape Go's JSON decoder cannot parse -- a runtime failure on every create and update, with nothing in `pnpm type-check` or `pnpm lint` positioned to see it: both check the request is well-typed TypeScript, not that the string it produces is a string Go can read. Changed both to value-format="YYYY-MM-DDTHH:mm:ssZ" -- dayjs's Z token renders the picker's own local offset, which is what a zero-nanosecond time.Time (anything without a database column storing sub-second precision) round-trips to on either side of the wire; confirmed separately against Go's actual json.Marshal/Unmarshal, not assumed from the RFC. The search filter needed the same fix, not just the form: GetPageReq binds a `time.Time` query field via `form:"..."` (dto.go.template), and gin's own default for an untagged time.Time binding is also RFC3339 -- the same failure mode on the query side, one call the report didn't name but the same root cause reaches. This is a runtime behaviour change no compiler catches, so it was verified as one: a Go program exercising encoding/json directly (not assumed from reading the RFC) confirmed a zero-nanosecond time.Time marshals to plain RFC3339 with no fractional seconds, and unmarshals correctly from both a numeric offset and a literal Z. Separately, a Node script loaded go-admin-ui's own installed dayjs 1.11.21 with the customParseFormat plugin -- the same plugin element-plus's date-picker extends dayjs with -- and called the same parseDate path date-picker panel.mjs uses (time-picker/src/utils.ts, no strict flag passed, so lenient parsing): formatting with this value-format produced a valid submission string, and parsing either an offset or a literal-Z string back with the same format produced a valid, correctly-valued date -- covering create, edit prefill, and update in the two directions that matter (browser to Go, Go to browser) without needing a live backend. --- template/v4/vue.go.template | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/template/v4/vue.go.template b/template/v4/vue.go.template index de42dad0..f40e3b10 100644 --- a/template/v4/vue.go.template +++ b/template/v4/vue.go.template @@ -99,7 +99,7 @@ {{- else}} @@ -223,7 +223,7 @@ {{- else if eq .HtmlType "textarea"}}