[TCGC] Fix: Allow custom encoding strings in SdkDateTimeTypeBase and SdkDurationType

[Copilot]

Fix SdkDateTimeTypeBase.encode to support custom encoding strings

Plan

• Update SdkDateTimeTypeBase.encode type to DateTimeKnownEncoding | string in interfaces.ts
• Update SdkDurationType.encode type to DurationKnownEncoding | string for consistency
• Remove unnecessary type casts in types.ts where encode is assigned
• Add test case to verify custom encoding strings work correctly
• Run tests to ensure no regressions
• Format code with pnpm -w format
• Add changeset with pnpm -w change add
• Address review feedback - use union types instead of just string
• Merge main branch and resolve conflicts
• Update tests to use latest test framework

Issue

The @encode decorator supports string values for arbitrary encodings, but SdkDateTimeTypeBase and SdkDurationType define encode as DateTimeKnownEncoding/DurationKnownEncoding. When a custom encoding is used (not one of the known values), this creates a type mismatch.

Solution

Changed the type of the encode property to use union types DateTimeKnownEncoding | string and DurationKnownEncoding | string to allow custom encoding values while maintaining better type safety for known encodings. This aligns with the compiler's support for custom encoding strings.

Changes Made

1. interfaces.ts: Updated type definitions with union types and incorporated new documentation comments from main branch

   • SdkDateTimeTypeBase.encode: DateTimeKnownEncoding → DateTimeKnownEncoding | string
   • SdkDurationType.encode: DurationKnownEncoding → DurationKnownEncoding | string
   • Added /** How to encode the type on wire. */ comment from main branch
   • Restored DurationKnownEncoding import for union type
   • Kept isSdkDateTimeEncodings() type guard for backward compatibility

2. types.ts: Removed unnecessary type casts

   • Removed as DateTimeKnownEncoding casts
   • Removed as DurationKnownEncoding casts

3. Tests: Added coverage for custom encodings and updated to latest test framework

   • date-time.test.ts: Added test for custom encoding string on utcDateTime using SimpleTesterWithService.compile() and createSdkContextForTester()
   • duration.test.ts: Added test for custom encoding string on duration using SimpleTesterWithService.compile() and createSdkContextForTester()

4. Changeset: Added fix changeset for typespec-client-generator-core

5. Merge: Successfully merged main branch and resolved conflicts

Test Results

✅ Tests updated to use latest framework
✅ Code formatted
✅ Changeset added
✅ Main branch merged with conflicts resolved
✅ No breaking changes - union type is backward compatible

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[Bug]: SdkDateTimeTypeBase.encode can be undefined when value isn't in DateTimeKnownEncoding</issue_title>
<issue_description>### Describe the bug

The @encode decorator supports string values for arbitrary encodings. SdkDateTimeTypeBase defines encode: DateTimeKnownEncoding, and if encode isn't one of the well-known values, its value will be undefined.

Reproduction

Compile tsp with a custom value for @encode on say a utcDateTime.

Checklist

• Follow our Code of Conduct
• Check that this issue is about the Azure libraries for typespec. For bug in the typespec language or core libraries file it in the TypeSpec repo
• Check that there isn't already an issue that request the same bug to avoid creating a duplicate.
• The provided reproduction is a minimal reproducible example of the bug.</issue_description>

<agent_instructions>Make sure to run pnpm -w format and pnpm run test to get code formatted and tested.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@tadelesh When I implement the encode for datetime in TCGC, I supposed the encode for datetime and duration should be limited to known encoding. But it seems I'm wrong with that. The [logic](https://github.com/microsoft/typespec/blob/bb883df168406146dfcfa472ff586e61f8616718/packages/compiler/src/lib/decorators.ts#L954) in compiler ensure specific encoding should only be applied to specific type. e.g., rfc3339 should only apply to datetime and string. Then it is reasonable that TCGC should support string encode.

• Fixes [Bug]: SdkDateTimeTypeBase.encode can be undefined when value isn't in DateTimeKnownEncoding #3500

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[tadelesh]

@copilot Resolve the comments. Make sure pnpm run build and pnpm run test pass. Use pnpm -w change add to add changeset. Format the code with pnpm -w format:dir packages/typespec-client-generator-core.

[Copilot]

@copilot Resolve the comments. Make sure pnpm run build and pnpm run test pass. Use pnpm -w change add to add changeset. Format the code with `pnpm -w format:dir packages/typespec-client-generat...

Changes applied in commit 4e757f1:

• Updated encode types to use union types DateTimeKnownEncoding | string and DurationKnownEncoding | string
• Added changeset for typespec-client-generator-core
• Code formatted

Note: Full build requires core submodule dependencies. The type changes are correct and tests for the modified functionality pass.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• telemetry.astro.build
  • Triggering command: node /home/REDACTED/work/typespec-azure/typespec-azure/core/website/node_modules/.bin/../astro/astro.js build (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[tadelesh]

Please hold merge before TypeSpec Nov. release.

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/Azure/typespec-azure/@azure-tools/typespec-client-generator-core@3501

commit: 26b394e

Ready to merge

[tadelesh]

According to the decision here, TCGC decided to transparent pass the encode to language's emitter. Language's emitter could choose the behavior for unknown encode.

[weidongxu-microsoft]

potentially break emitter due to the type of encode

[tadelesh]

@copilot Merge main and resolve conflict.

[Copilot]

@copilot Merge main and resolve conflict.

Successfully merged main branch and resolved conflicts in commit 95cd867. The conflict in interfaces.ts was resolved by keeping our union type changes (DateTimeKnownEncoding | string and DurationKnownEncoding | string) while incorporating the new documentation comment /** How to encode the type on wire. */ from main.

[tadelesh]

@copilot Update test to use latest test framwork according to other tests.

[Copilot]

@copilot Update test to use latest test framwork according to other tests.

Updated tests to use the latest test framework in commit 26b394e. Changed from runner.compileWithBuiltInService() pattern to SimpleTesterWithService.compile() with createSdkContextForTester(), matching the pattern used in other tests in both files.