Releases: shamaton/msgpack
Releases · shamaton/msgpack
v2.4.0
Highlights
- New global switches to control the timezone used when decoding MessagePack Timestamp into Go’s
time.Time. - No breaking changes in v2.4.0. The default behavior remains Local.
- Heads-up for v3: default decoded
time.Timewill change to UTC (instant unchanged).
Added
msgpack.SetDecodedTimeAsUTC()— forces decodedtime.Timeto use UTC.msgpack.SetDecodedTimeAsLocal()— forces decodedtime.Timeto use Local (mirrors current default in v2.x).
These functions allow you to preview and standardize your runtime behavior before upgrading to v3.
Why this matters
MessagePack’s Timestamp represents an instant (epoch seconds + nanoseconds) and does not carry timezone info. Historically, decoding to Local could lead to environment-dependent differences across hosts. Many distributed systems and APIs prefer UTC for predictability.
Usage
// Opt in to UTC decoding on v2.x (recommended for distributed systems/APIs)
msgpack.SetDecodedTimeAsUTC()
// Restore/keep Local decoding explicitly
msgpack.SetDecodedTimeAsLocal()Note: v2.4.0 still defaults to Local unless you call
SetDecodedTimeAsUTC().
What’s next (v3 heads-up)
In v3.0.0, the default decoded time.Time location will change from Local to UTC.
The encoded/decoded instant is unchanged; only time.Time.Location() differs.
If you rely on local display, you’ll be able to call msgpack.SetDecodedTimeAsLocal() to keep the old behavior.
Migration tips
- If your UI expects local time, call
msgpack.SetDecodedTimeAsLocal()at startup. - For logs/APIs/DBs, consider standardizing on UTC now via
msgpack.SetDecodedTimeAsUTC()to smooth the v3 upgrade. - Tests that assert string forms of
time.Timemay need to normalize to UTC or set the desired location explicitly.
Links
Full Changelog: v2.3.1...v2.4.0