time.Time unmarshaling always converts to local timezone, losing original timezone information

[dimahc]

Summary

When unmarshaling time.Time values from msgpack, the library always converts timestamps to the local system timezone, even when the original time had explicit timezone information (including UTC). This behavior is problematic for applications that need to preserve timezone information or work with UTC timestamps consistently.

Expected Behavior

• time.Time values should preserve their original timezone after msgpack marshal/unmarshal round-trip
• UTC timestamps should remain in UTC after unmarshaling
• Timestamps with specific timezones should maintain their timezone information

Current Behavior

• All time.Time values are converted to the local system timezone during unmarshaling
• Original timezone information is lost
• This creates inconsistency between marshaled and unmarshaled data

Reproduction Example

package main

import (
    "fmt"
    "time"
    "github.com/shamaton/msgpack/v2"
)

func main() {
    // Create a UTC timestamp
    original := time.Date(2025, 6, 12, 14, 45, 0, 0, time.UTC)
    fmt.Printf("Original: %s (Location: %s)\n", original, original.Location())
    
    // Marshal to msgpack
    data, err := msgpack.Marshal(original)
    if err != nil {
        panic(err)
    }
    
    // Unmarshal back
    var result time.Time
    err = msgpack.Unmarshal(data, &result)
    if err != nil {
        panic(err)
    }
    
    fmt.Printf("Result:   %s (Location: %s)\n", result, result.Location())
    fmt.Printf("Equal: %v\n", original.Equal(result))
    fmt.Printf("Same location: %v\n", original.Location() == result.Location())
}

Output:

Original: 2025-06-12 14:45:00 +0000 UTC (Location: UTC)
Result:   2025-06-12 16:45:00 +0200 CEST (Location: Local)  
Equal: true
Same location: false

Impact

This behavior is burdensome because:

1. Data Consistency: Applications expecting UTC timestamps receive local time instead
2. Cross-timezone Applications: Services running in different timezones will interpret the same msgpack data differently
3. API Contracts: APIs that specify UTC timestamps cannot rely on msgpack serialization
4. Workarounds Required: Applications must implement custom post-processing to convert timestamps back to their expected timezone

[shamaton]

Thanks for the clear report and repro!
We’ve addressed this in v3 by changing the default decoded time.Time location to UTC (instant unchanged). We also added global switches to control behavior:

msgpack.SetDecodedTimeAsUTC()   // v3 default
msgpack.SetDecodedTimeAsLocal() // restore v2-like behavior

For details and migration notes, please see the PR:
#52