proposal: time: add RFC 9557 Internet Extended Date/Time Format (IXDTF) support

[8beeeaaat]

Proposal Details

This proposal suggests adding support for RFC 9557 Internet Extended Date/Time Format (IXDTF) to Go's time package. IXDTF is a backward-compatible extension of RFC 3339 that adds optional suffix elements for timezone names and metadata.

https://www.rfc-editor.org/rfc/rfc9557.html

Background

RFC 9557, published in 2024, extends RFC 3339 by allowing additional suffix information while maintaining full backward compatibility. This enables more precise time representation for internationalization, calendar systems, and metadata preservation.

Current State

time package has excellent RFC 3339 support with optimized parsing and formatting functions (parseRFC3339, appendFormatRFC3339). However, it cannot handle IXDTF's extended format.

https://github.com/golang/go/blob/master/src/time/format_rfc3339.go

Examples

Basic RFC 3339:
2006-01-02T15:04:05Z
2006-01-02T15:04:05.999999999-07:00

IXDTF with timezone:
2006-01-02T15:04:05Z[UTC]
2006-01-02T15:04:05+09:00[Asia/Tokyo]

IXDTF with extensions:
2006-01-02T15:04:05Z[u-ca=japanese]
2006-01-02T15:04:05+09:00[Asia/Tokyo][u-ca=japanese]

IXDTF with critical extensions:
2006-01-02T15:04:05Z[!u-ca=japanese]

Motivation

1. Standards Compliance: RFC 9557 is an official IETF standard extending RFC 3339
2. Internationalization: Better support for non-Gregorian calendars and localization
3. Interoperability: Compatibility with systems already using IXDTF
4. Metadata Preservation: Ability to preserve timezone and calendar information in serialization

Proposed API (Initial Concept)

// New constants
const (
    RFC9557TimeZone     = "2006-01-02T15:04:05Z07:00[time-zone]"
    RFC9557NanoTimeZone = "2006-01-02T15:04:05.999999999Z07:00[time-zone]"
)

// Extension information structure
type IXDTFExtensions struct {
    TimeZone  string            // IANA timezone name
    Tags      map[string]string // Extension tags
    Critical  map[string]bool   // Critical flags
}

// New parsing/formatting functions
func (t Time) appendFormatRFC9557(b []byte, nanos bool, ext IXDTFExtensions) []byte
func parseRFC9557[bytes []byte | string](s bytes, local *Location) (Time, IXDTFExtensions, bool)

[ianlancetaylor]

This seems like it could be in a third party package. Is this used widely enough that we should add it to the standard library now? Since this was published in 2024, should we wait to see how popular it becomes? See https://go.dev/doc/faq#x_in_std.

[8beeeaaat]

Thank you for the feedback!

I agree with starting as a third-party package approach. You're right that RFC 9557 was published in 2024, making it relatively new. Additionally, the ECMAScript TC39 Temporal proposal that helped inform RFC 9557 development is still at Stage 3, not yet reaching Stage 4 (final specification) https://github.com/tc39/proposal-temporal/milestone/2

I'll explore the possibility of proposing this as something like a golang.org/x/time/ixdtf package to validate adoption and API design first. 👍

[seankhliao]

A package under golang.org/x is not any faster or better. When we say third party, we mean not maintained by the Go team.

[dsnet]

As a data point for what @seankhliao said, the encoding/json/v2 effort started off in github.com/go-json-experiment/json. There was never a golang.org/x module for it.

Regarding adding support for it in the time package, I'm not sure this is a good fit. The RFC allows for arbitrary key-value pairs to be attached to a timestamp, meaning this isn't just a timestamp, but a timestamp with quite a bit of other metadata. One could argue that this is actually a key-value store that happens to always have a timestamp. I'm not sure time.Time should grow to include this metadata (it's already 24B, let's keep it small).

A separate data structure that includes or embeds a time.Time with this support sounds more reasonable.

[8beeeaaat]

Thank you all for the thoughtful feedback.
I realize now that I misunderstood the intent behind some of the comments, and I apologize for any confusion that may have caused.

Based on the discussion, I agree that instead of aiming for direct inclusion in the Go standard library at this stage, it would be more appropriate to start as a third-party implementation in a personal repository. If it proves valuable in practice, we could then reconsider proposing it for inclusion in the future.

I will proceed with developing this in a separate repository and share updates once it becomes available!

[8beeeaaat]

📝 I’ve published a third-party module

https://pkg.go.dev/github.com/8beeeaaat/ixdtf
https://github.com/8beeeaaat/ixdtf