Replace sscanf datetime parsing with Go-inspired byte-arithmetic

[schlubbi]

Summary

Replace all three sscanf()-based datetime parsing blocks (DATETIME/TIMESTAMP, DATE, TIME) in cast.c with inline byte-arithmetic parsers inspired by Go's go-sql-driver/mysql parseDateTime() implementation, and replace rb_funcall(rb_cTime, :utc, 7, ...) Time object construction with Ruby's C-level rb_time_timespec_new() API.

Motivation

sscanf → byte-arithmetic parsing

sscanf() is a general-purpose format parser with overhead from format string interpretation, locale handling, and variadic argument processing. Go's MySQL driver avoids this entirely by operating directly on the byte buffer with simple arithmetic (byte - '0'), using length-based dispatch to determine the datetime format.

rb_funcall → rb_time_timespec_new (per byroot's suggestion)

rb_funcall(rb_cTime, :utc, 7, ...) goes through Ruby method dispatch, creates 7 INT2NUM VALUE arguments, unpacks them back to C integers in time_arg(), and converts to epoch via timegmw(). rb_time_timespec_new() skips all of that — we compute the epoch in C and hand it directly to the allocator.

For UTC epoch computation, uses Howard Hinnant's civil_to_days algorithm (the foundation of C++20 std::chrono::sys_days) which handles the full MySQL 1000–9999 year range. POSIX timegm() was considered but fails for tm_year < 0 on macOS; Ruby's own timegm_noleapsecond() handles this but is static internal.

What Changed

Byte-arithmetic parsing

New helpers in cast.c inspired by Go's bToi, parseByte2Digits, parseByteYear, parseByteNanoSec:

Function	Purpose	Go equivalent
byte_to_digit(b)	Single ASCII char → int	bToi()
parse_2digits(p)	2-byte parse (month, day, hour, min, sec)	parseByte2Digits()
parse_4digits(p)	4-byte year parse	parseByteYear()
parse_microseconds(p, len)	1-6 fractional digits → microseconds	parseByteNanoSec()

Replaced parsing blocks:

• DATETIME/TIMESTAMP: Length-based dispatch (10/19/21-26 bytes) with direct byte access at known offsets
• DATE: Exact 10-byte parse
• TIME: 8-15 byte parse with fractional seconds

C-level Time construction

Before	After
rb_funcall(rb_cTime, id_utc, 7, INT2NUM(y), ...)	rb_time_timespec_new(&ts, INT_MAX-1)
Method dispatch + 7 VALUE args + time_arg() + timegmw()	Direct epoch → Time allocation

• civil_to_epoch_utc() — Hinnant algorithm for UTC (portable, no timegm)
• mktime() — standard C for local time with DST handling
• trilogy_make_time() — unified helper for both DATETIME and TIME paths
• Removed unused id_local, id_localtime, id_utc

Tests

20 new test cases covering:

• Fractional seconds with 1-6 digits of precision (Go-ported)
• Zero date/datetime handling
• Specific date and datetime parsing validation
• TIME column with microsecond precision
• Epoch edge cases: Unix epoch zero, pre-1970 dates, leap year Feb 29, non-leap century (1900), far future (9999), MySQL minimum year (1000), leap year with local timezone

Profile Results

CPU-time isolated benchmark (per-row incremental casting cost, GC disabled):

Original (sscanf + rb_funcall):    ~208 ns/row
After byte-arithmetic parsing:      ~75 ns/row  (2.7× faster)
After rb_time_timespec_new:          ~3 ns/row  (72× faster)

The casting overhead is now indistinguishable from no-casting in benchmark-ips measurements — all datetime benchmarks report "same-ish: difference falls within error."

Files

File	Change
contrib/ruby/ext/trilogy-ruby/cast.c	Replace sscanf + rb_funcall with byte-arithmetic + C-level Time API
contrib/ruby/test/cast_test.rb	Add 20 test cases (Go-ported + epoch edge cases)

Test Results

45 runs, 164 assertions, 0 failures, 0 errors, 0 skips

[byroot]

The remaining casting cost is dominated by rb_funcall(rb_cTime, id_utc, 7, ...) at ~106 ns — Ruby's Time object construction, which is irreducible without changing the API contract.

There are a number of C-level APIs to construct ruby time objects: https://github.com/ruby/ruby/blob/45dbc5a4a24cac30771b8c8353abbbfd35fa86b8/include/ruby/internal/intern/time.h

[schlubbi]

The remaining casting cost is dominated by rb_funcall(rb_cTime, id_utc, 7, ...) at ~106 ns — Ruby's Time object construction, which is irreducible without changing the API contract.

There are a number of C-level APIs to construct ruby time objects: https://github.com/ruby/ruby/blob/45dbc5a4a24cac30771b8c8353abbbfd35fa86b8/include/ruby/internal/intern/time.h

Thanks for the pointer! addressed in a81c3e6

[byroot]

I like that change a lot.

I think we should just remove a bit of boiler plate from the tests, and I'm not convinced it's really worth committing the benchmark. But other than that 👍

@composerinteralia any opinions?

[byroot]

Ah and I ran the extra tests on main, to make sure the behavior didn't change.

Either way, not having to do a method dispatch is a huge win.

[schlubbi]

I like that change a lot.

I think we should just remove a bit of boiler plate from the tests, and I'm not convinced it's really worth committing the benchmark. But other than that 👍

🎈
Bumped the precision of the existing datetime/time columns and am reusing them in the tests now. Benchmark script is gone from the PR too.