Skip to content

Fix Go example generator emitting invalid Go for RFC7231 datetime values - #4984

Open
JiaqiZhang-Dev with Copilot wants to merge 9 commits into
mainfrom
copilot/fix-invalid-go-rfc7231-datetime
Open

Fix Go example generator emitting invalid Go for RFC7231 datetime values#4984
JiaqiZhang-Dev with Copilot wants to merge 9 commits into
mainfrom
copilot/fix-invalid-go-rfc7231-datetime

Conversation

Copilot AI commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

The example generator produced uncompilable Go for utcDateTime properties encoded as rfc7231. getTimeValue's formatMap (in packages/typespec-go/src/codegen/core/example.ts) only handled RFC1123 and RFC3339, so RFC7231 fell through to the Unix-timestamp path — wrapping an unquoted, non-numeric date string in strconv.ParseInt. This regressed in Azure/autorest.go#1992, which switched the TypeSpec adapter to emit RFC7231 but updated servers.ts/operations.ts/models.ts/type.ts while missing example.ts.

Actual (broken):

LastExecuted: to.Ptr(func() time.Time { t, _ := strconv.ParseInt(05 May 2021 12:00:23 GMT, 10, 64); return time.Unix(t, 0).UTC()}()),

Now:

LastExecuted: to.Ptr(func() time.Time { t, _ := time.Parse(time.RFC1123, "05 May 2021 12:00:23 GMT"); return t}()),

Changes

  • core/example.ts: Add RFC7231: helpers.RFC1123Format to getTimeValue's formatMap, mirroring the existing mapping in fake/servers.ts. Both share the Go time.RFC1123 layout.
  • Changelog: Add a fix chronus entry for @azure-tools/typespec-go.

@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
2 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

Co-authored-by: JiaqiZhang-Dev <194873822+JiaqiZhang-Dev@users.noreply.github.com>
@microsoft-github-policy-service microsoft-github-policy-service Bot added the emitter:go Issues for @azure-tools/typespec-go emitter label Jul 21, 2026
Co-authored-by: JiaqiZhang-Dev <194873822+JiaqiZhang-Dev@users.noreply.github.com>
Copilot AI changed the title [WIP] Fix invalid Go generation for RFC7231 datetime values Fix Go example generator emitting invalid Go for RFC7231 datetime values Jul 21, 2026
Copilot AI requested a review from JiaqiZhang-Dev July 21, 2026 05:29
@JiaqiZhang-Dev

Copy link
Copy Markdown
Member

@copilot

  1. please follow this doc to add a scenario unitest for this change: https://github.com/Azure/typespec-azure/blob/main/packages/typespec-go/docs/development.md
    2 you need to use pnpm change add to update the changelog, also help update the process for this doc: https://github.com/Azure/typespec-azure/blob/main/packages/typespec-go/docs/development.md#step-5-make-a-pr
  2. you need to update package version in the package.json

…update dev doc

Co-authored-by: JiaqiZhang-Dev <194873822+JiaqiZhang-Dev@users.noreply.github.com>

Copilot AI commented Jul 21, 2026

Copy link
Copy Markdown
Contributor Author

@copilot

  1. please follow this doc to add a scenario unitest for this change: https://github.com/Azure/typespec-azure/blob/main/packages/typespec-go/docs/development.md
    2 you need t...

Addressed all three in the latest commit:

  1. Added an emitter scenario unit test (test/unittest/scenarios/rfc7231-datetime-sample.md, per the development doc) that compiles a @encode("rfc7231") utcDateTime property and snapshots the generated sample. It asserts the value is parsed with time.Parse(time.RFC1123, ...); I verified that reverting the fix makes the snapshot fail gofmt -s (uncompilable Go).
  2. Regenerated the changelog with pnpm change add (replacing the hand-written change file), and updated Step 5 of the development doc to use pnpm change add.
  3. Bumped @azure-tools/typespec-go to 0.15.1 in package.json, and documented the version-bump step in the development doc.

@pkg-pr-new

pkg-pr-new Bot commented Jul 21, 2026

Copy link
Copy Markdown

Open in StackBlitz

npm i https://pkg.pr.new/@azure-tools/typespec-go@4984

commit: 3dc1ab9

@JiaqiZhang-Dev

Copy link
Copy Markdown
Member

waiting for this pr merged: #4991

@JiaqiZhang-Dev

Copy link
Copy Markdown
Member

@copilot resolve the merge conflicts in this pull request

…o-rfc7231-datetime

# Conflicts:
#	packages/typespec-go/docs/development.md

Co-authored-by: JiaqiZhang-Dev <194873822+JiaqiZhang-Dev@users.noreply.github.com>

Copilot AI commented Jul 22, 2026

Copy link
Copy Markdown
Contributor Author

@copilot resolve the merge conflicts in this pull request

Resolved the merge conflicts by merging origin/main into this branch (merge commit af66c33). The only conflict was in packages/typespec-go/docs/development.md, where main reworded the changelog step; I kept the version-bump step and the pnpm change add wording (matching the repo convention). The RFC7231 fix in core/example.ts, the scenario test, and the version bump are all intact.

@JiaqiZhang-Dev
JiaqiZhang-Dev marked this pull request as ready for review July 22, 2026 03:27
@azure-sdk-automation

Copy link
Copy Markdown
Contributor

All changed packages have been documented.

  • @azure-tools/typespec-go
Show changes

@azure-tools/typespec-go - fix ✏️

Fix the example generator emitting incorrect code for rfc7231 datatime.

@azure-sdk-automation

Copy link
Copy Markdown
Contributor

You can try these changes here

🛝 Playground 🌐 Website

@github-actions

github-actions Bot commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

Go emitter diff

Baseline gh:654134313d19dce661907728d0985920f30d0111 vs this PR.

No changes to generated output.

Rendered diff: inline on the run summary, or the emitter-diff-go-html artifact.

Informational check (core/eng/emitter-diff); does not block the PR.

Comment thread packages/typespec-go/docs/development.md Outdated
Comment thread packages/typespec-go/package.json Outdated
Co-authored-by: JiaqiZhang-Dev <194873822+JiaqiZhang-Dev@users.noreply.github.com>
Location: to.Ptr("eastus"),
Properties: &testmodule.WidgetProperties{
Description: to.Ptr("my widget"),
LastExecuted: to.Ptr(func() time.Time { t, _ := time.Parse(time.RFC1123, "05 May 2021 12:00:23 GMT"); return t }()),

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Callers should never need to manually parse time.Time into the wire format (we go to great lengths to not leak that implementation detail). Why do we need to do this here?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Since the example value is in wire format: 05 May 2021 12:00:23 GMT, we need to manually parse it into time.Time. For sdk customers, they don't need this logic, just give the time.Time is ok.

I'm not sure if you mean that we should analyze the wire format in the code, and then generate unified code like to.Ptr(time.Date(2021, time.May, 5, 12, 0, 23, 0, time.UTC))

@jhendrixMSFT jhendrixMSFT Jul 27, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Your example is correct.

The emitted code handles conversion to the correct wire format. All we should need to know is if we need to emit time.UTC or time.Local (the former should be the vast majority of cases.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

FYI I'm going to fix this as part of #4956 which is in progress.

@jhendrixMSFT

Copy link
Copy Markdown
Member

I don't see any changes in the generated diff, is this expected?

@JiaqiZhang-Dev

Copy link
Copy Markdown
Member

I don't see any changes in the generated diff, is this expected?

Yes, since we haven’t had a test about RFC7231 before, there’s no change in the generated diff.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

emitter:go Issues for @azure-tools/typespec-go emitter

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Example generator emits invalid Go for RFC7231 datetime values (regression from #1992)

4 participants