Support default millisecond timestamp precision for custom services

[SamRemis]

Overview:

Currently, only the ISO8601 timestamp format supports sub-second precision (microseconds). However, the Smithy standard specifies millisecond precision as the maximum supported granularity.

This mismatch is causing issues for bedrock-agentcore, which requires millisecond-precise timestamps to function correctly. This PR adds service-level millisecond precision support that complies with Smithy standards while maintaining backward compatibility.

Implementation:

Introduces a new creating-serializer event that allows services to override timestamp precision during serializer creation. We can customize services to allow them to opt into millisecond precision without requiring client-side configuration changes.

Alternatives Considered:

• Client-side configuration: Environment variables, config files, or SDK parameters. Rejected because this service needs millisecond precision by default - requiring all customers to configure this would create a poor user experience.
• Operation-level precision: More granular control per API call. Would require significant architectural changes (similar to parsers.py request-level overrides) that exceed current requirements.
• Global default change: Change all services to millisecond precision. Quickly dismissed as a breaking change.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.17%. Comparing base (bbed2c0) to head (2700e8e).
⚠️ Report is 196 commits behind head on develop.
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #3568      +/-   ##
===========================================
+ Coverage    93.13%   93.17%   +0.03%     
===========================================
  Files           68       68              
  Lines        15336    15411      +75     
===========================================
+ Hits         14283    14359      +76     
+ Misses        1053     1052       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[hssyoo]

Is it possible to pass timestamp_precision to the serialize_to_request method instead? I think it would be a bit cleaner if serializer objects don't need to be tied to a specific timestamp_precision value. I haven't looked into if it's possible to grab the value at the method call sites and I don't feel super strongly about it so feel free to merge if we think this is the best place

[SamRemis]

I like that idea better in theory, but it would be a hackey shim. Right now our serialization logic just passes in the value and shape. At this point in the code, we have access to the following (assuming JSON parser):

• self (the whole serializer object) - storing something here wouldn't be an option for setting it on a method level due to race conditions that could occur
• The "key" that it will be serialized to
• The modeled shape
• The DateTime object that we are serializing

That leaves us with two options:

1. Add this to the operation model somehow, probably using service-2.sdk-extras.json or some sort of model pre-processing. That would get pretty difficult to maintain as these services grow
2. Find some way to pass around an operation_context of sorts that contains it, and add the precision to the context in serialize_to_request.
   2a. We could pass around a dictionary to these methods, which gets messy since these are generally inside a structure (maybe nested a few layers), so we have to make sure that persists.
   2b. contextvars would be the other solution I could think of here, but I'd be concerned about behavior if for some reason the context var didn't exist. Maybe that's a non-issue since we would have just created the context in the serialize_to_request method.

Based on all of this, do you have a preferred solution? I'm open to chat here, but right now I'd say we should either go with the current solution or 2b.

[jonathan343]

Dropping some initial comments after the first pass