8000 This PR introduces comprehensive support for C++ std::chrono types by FranciscoThiesen · Pull Request #2450 · simdjson/simdjson · GitHub
[go: up one dir, main page]

Skip to content

Conversation

@FranciscoThiesen
Copy link
Member

Summary

This PR introduces comprehensive support for C++ std::chrono types (durations and time_points) in simdjson's static reflection API,
enabling automatic JSON serialization and deserialization of temporal data.

Problem Solved

Previously, structs containing std::chrono::duration or std::chrono::time_point members could not be serialized/deserialized using
simdjson's static reflection features. This limitation forced users to manually convert temporal data or create custom serialization
logic.

Implementation Details

  1. Serialization Support (include/simdjson/generic/ondemand/json_builder.h)
  • Added template specializations for std::chrono::duration<Rep, Period>
  • Added template specializations for std::chrono::time_point<Clock, Duration>
  • Both types serialize to milliseconds as JSON integers for precision and compatibility
  1. Deserialization Support (include/simdjson/generic/ondemand/std_deserialize.h)
  • Added tag_invoke overloads for deserializing durations from milliseconds
  • Added tag_invoke overloads for deserializing time_points from milliseconds since epoch
  • Properly handles conversion between different duration units and clock types
  1. Template Instantiation Fix (include/simdjson/generic/ondemand/json_string_builder-inl.h)
  • Fixed digit_count() function to explicitly cast to uint32_t or uint64_t
  • Resolves compilation errors when serializing chrono types with various integer representations
  1. Comprehensive Testing (tests/builder/static_reflection_chrono_test.cpp)
  • Round-trip tests for structs containing time_point members
  • Tests for multiple duration types (milliseconds, seconds, minutes)
  • Validation of different clock types (system_clock, steady_clock)
  • Ensures millisecond precision is maintained through serialization

Key Design Decisions

  • Milliseconds as standard unit: Provides good balance between precision and JSON number range
  • Integer representation: More efficient and portable than ISO 8601 strings
  • Non-intrusive design: No modifications needed to user structs
  • Template-based approach: Works automatically with any chrono duration/time_point type

Example Usage

  struct Meeting {
      std::string title;
      std::chrono::system_clock::time_point start_time;
      std::chrono::minutes duration;
  };

  // Automatically serializes to:
  // {"title":"Team Standup","start_time":1736951234567,"duration":30000}

  Meeting m = doc.get<Meeting>(); // Deserializes seamlessly

Testing

All tests pass with reflection-enabled clang compiler. The implementation maintains exact millisecond precision through round-trip
serialization.

@lemire
Copy link
Member
lemire commented Sep 16, 2025

@FranciscoThiesen Running tests.

@toughengineer
Copy link
Contributor
  • Integer representation: More efficient and portable than ISO 8601 strings

@FranciscoThiesen, how did you evaluate and compare efficiency?

@lemire
Copy link
Member
lemire commented Sep 21, 2025

@toughengineer I have put this PR on hold because I am not certain that there is a widely accepted way to serialize these values.

Currently, if one relies on C++26 reflection, one will get an implementation-specific serialization (which is not great), but I am not certain how we should fix this since the standard tells us nothing about serialization.

@toughengineer
Copy link
Contributor

@lemire, I was merely curious about the efficiency claim.

I personally think ISO 8601 is the way to go, it's better than integers in many ways. E.g. what about clocks with different epochs, and what about std::chrono::zoned_time?
And also there are ways to serialize/parse ISO 8601 date and time efficiently.

@lemire
Copy link
Member
lemire commented Sep 23, 2025

@toughengineer Right. That makes a lot of sense (using ISO 8601).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

0