[Feature #21264] Replace C extension with pure Ruby implementation for Ruby >= 3.3

[jinroq]

Summary

https://bugs.ruby-lang.org/issues/21264

Rewrite Date and DateTime C extension as pure Ruby, targeting Ruby 3.3+.
Ruby < 3.3 continues to use the existing C extension as before.

• Ruby >= 3.3: Pure Ruby implementation (~7,900 lines across 10 files in lib/date/)
• Ruby < 3.3: Existing C extension (ext/date/) compiled via rake-compiler

All 143 tests pass with 162,593 assertions on both paths.

Motivation

• Improves portability: no C compiler required for Ruby 3.3+
• Makes the codebase easier to read, debug, and contribute to
• Enables Ractor compatibility without C-level thread safety concerns
• Aligns with the broader Ruby ecosystem trend toward pure Ruby default gems

Architecture

The version branch (RUBY_VERSION >= "3.3") is applied at three layers:

Layer	Ruby >= 3.3	Ruby < 3.3
lib/date.rb	require_relative pure Ruby files	require 'date_core' (C ext)
ext/date/extconf.rb	Generates dummy Makefile (no-op)	create_makefile('date_core')
Rakefile	task :compile is a no-op	Rake::ExtensionTask compiles C ext

C option	Purpose	Pure Ruby
USE_PACK	Bit-pack mon/mday/hour/min/sec into a single integer for memory efficiency	Not needed — uses standard instance variables (@nth, @jd, @df, @sf, @of, @sg)
TIGHT_PARSER	Stricter Date._parse (disabled by default in C via /* #define TIGHT_PARSER */)	Matches C default behavior (loose parser) — TIGHT_PARSER logic is not implemented

Timezone table auto-generation

lib/date/zonetab.rb is now auto-generated from ext/date/zonetab.list (the same source used by gperf to generate zonetab.h for the C extension). This
ensures the Ruby and C timezone tables stay in sync automatically.

Component	Description
ext/date/generate-zonetab-rb	Ruby script that reads zonetab.list and produces the Ruby hash table
ext/date/prereq.mk	update-zonetab target now runs generate-zonetab-rb alongside gperf
.github/workflows/update.yml	CI commits regenerated lib/date/zonetab.rb alongside ext/date changes

Pure Ruby file structure

File	Description
lib/date/core.rb	Date class (civil, ordinal, commercial, JD, arithmetic, comparison)
lib/date/parse.rb	Date._parse, _iso8601, _rfc3339, _rfc2822, _xmlschema, _jisx0301
lib/date/datetime.rb	DateTime subclass (hour, min, sec, offset)
lib/date/strptime.rb	strptime parsing
lib/date/strftime.rb	strftime formatting
lib/date/zonetab.rb	Timezone offset table (auto-generated from zonetab.list)
lib/date/patterns.rb	Regex patterns for parsing
lib/date/constants.rb	Calendar reform constants (ITALY, ENGLAND, GREGORIAN, etc.)
lib/date/time.rb	Date#to_time, Time#to_date, Time#to_datetime
lib/date/version.rb	Date::VERSION

Performance note

DateTime is deprecated and no performance optimization has been done for it. The benchmark numbers for DateTime are provided for reference only.

Changes

• Rakefile: Branch on RUBY_VERSION for compile/test task setup; test depends on compile for Ruby < 3.3
• date.gemspec: Include both lib/**/*.rb and ext/date/* files; set extensions
• ext/date/extconf.rb: Generate dummy Makefile on Ruby >= 3.3, build C ext otherwise
• ext/date/generate-zonetab-rb (new): Script to auto-generate lib/date/zonetab.rb from ext/date/zonetab.list
• ext/date/prereq.mk: Add generate-zonetab-rb to update-zonetab target
• .github/workflows/update.yml: Include lib/date/zonetab.rb in auto-commit scope
• lib/date.rb: Branch on RUBY_VERSION for require path; add require 'timeout' for parse timeout support
• lib/date/*.rb (new): Pure Ruby implementation (10 files, ~7,900 lines)

Benchmark: C extension vs Pure Ruby (Ruby 4.0.1)

Date class methods

Method	C ext (i/s)	Pure Ruby (i/s)	Ratio
Date.new	3,974,217	1,531,119	38.5%
Date.new(no args)	4,509,731	1,415,434	31.4%
Date.civil	4,631,684	2,137,457	46.1%
Date.civil(sg)	4,372,123	2,026,949	46.4%
Date.civil(-1)	4,587,855	1,872,146	40.8%
Date.civil(neg)	4,477,827	2,084,786	46.6%
Date.jd	4,807,135	3,973,489	82.7%
Date.ordinal	2,982,925	2,208,698	74.0%
Date.commercial	2,476,732	1,799,799	72.7%
Date.today	175,435	443,836	253.0%
Date.valid_civil?	10,746,810	1,513,351	14.1%
Date.valid_civil?(false)	10,823,626	2,051,868	19.0%
Date.valid_ordinal?	4,160,590	1,625,978	39.1%
Date.valid_commercial?	3,178,432	580,553	18.3%
Date.valid_jd?	16,512,281	12,386,993	75.0%
Date.gregorian_leap?	14,950,071	8,380,877	56.1%
Date.gregorian_leap?(1900)	14,080,523	8,051,206	57.2%
Date.julian_leap?	16,991,200	10,169,182	59.8%

Date parse methods

Method	C ext (i/s)	Pure Ruby (i/s)	Ratio
Date._parse(iso)	239,001	1,506,581	630.4%
Date._parse(us)	118,865	644,263	542.0%
Date._parse(eu)	159,928	556,533	348.0%
Date._parse(rfc2822)	82,441	264,068	320.3%
Date.parse(iso)	212,655	720,361	338.7%
Date.parse(us)	112,487	411,137	365.5%
Date.parse(eu)	148,339	373,372	251.7%
Date.parse(compact)	133,285	731,634	548.9%
Date._strptime	2,737,334	1,412,082	51.6%
Date.strptime	1,390,385	943,652	67.9%
Date.strptime(complex)	1,116,618	373,480	33.4%
Date._iso8601	750,095	1,613,186	215.1%
Date._rfc3339	501,479	664,953	132.6%
Date._rfc2822	373,428	613,062	164.2%
Date._xmlschema	787,848	1,595,289	202.5%
Date._httpdate	397,646	688,085	173.0%
Date._jisx0301	733,059	1,425,575	194.5%
Date.iso8601	547,109	731,563	133.7%
Date.rfc3339	414,614	427,392	103.1%
Date.rfc2822	310,970	412,405	132.6%
Date.xmlschema	574,804	732,143	127.4%
Date.httpdate	302,846	439,218	145.0%
Date.jisx0301	540,940	687,365	127.1%

Date instance methods

Method	C ext (i/s)	Pure Ruby (i/s)	Ratio
Date#year	20,593,327	15,021,287	72.9%
Date#month	21,446,329	15,000,410	69.9%
Date#day	18,289,725	14,989,635	82.0%
Date#wday	19,708,683	15,560,398	79.0%
Date#yday	15,578,182	18,117,325	116.3%
Date#jd	18,533,155	20,384,518	110.0%
Date#ajd	7,244,720	5,030,639	69.4%
Date#mjd	11,192,998	19,249,248	172.0%
Date#amjd	9,935,512	2,221,272	22.4%
Date#ld	11,415,318	19,199,854	168.2%
Date#start	20,057,435	20,487,414	102.1%
Date#cwyear	4,475,221	18,366,865	410.4%
Date#cweek	4,523,128	18,683,158	413.1%
Date#cwday	20,551,980	11,273,834	54.9%
Date#leap?	18,147,973	9,743,760	53.7%
Date#julian?	17,546,611	10,199,752	58.1%
Date#gregorian?	17,932,339	13,141,146	73.3%
Date#sunday?	20,750,735	12,003,952	57.8%
Date#monday?	20,790,772	11,854,532	57.0%
Date#saturday?	20,400,215	11,924,834	58.5%

Date arithmetic / comparison

Method	C ext (i/s)	Pure Ruby (i/s)	Ratio
Date#+1	5,922,467	3,491,742	59.0%
Date#+100	5,719,971	3,531,438	61.7%
Date#-1	4,050,015	3,223,107	79.6%
Date#-Date	1,900,127	2,379,705	125.2%
Date#>>1	3,133,030	1,989,987	63.5%
Date#>>12	3,018,894	1,938,665	64.2%
Date#<<1	2,206,690	1,877,250	85.1%
Date#next_day	4,710,869	3,260,116	69.2%
Date#prev_day	4,041,438	3,046,170	75.4%
Date#next_month	2,742,850	1,900,557	69.3%
Date#prev_month	2,102,104	1,826,171	86.9%
Date#next_year	2,629,005	1,749,549	66.5%
Date#prev_year	1,836,359	1,687,470	91.9%
Date#succ	5,421,671	3,270,318	60.3%
Date#<=>	11,416,636	7,788,569	68.2%
Date#===	12,411,827	7,174,659	57.8%
Date#==	2,702,128	9,236,888	341.8%
Date#<	7,324,156	7,443,056	101.6%
Date#>	7,559,944	7,485,990	99.0%
Date#eql?	10,519,187	10,476,624	99.6%
Date#hash	13,768,431	10,380,449	75.4%

Date iteration / formatting / conversion

Method	C ext (i/s)	Pure Ruby (i/s)	Ratio
Date#upto(+30)	140,859	163,117	115.8%
Date#downto(-30)	114,805	161,888	141.0%
Date#step(+30,7)	711,797	834,724	117.3%
Date#to_s	3,751,091	4,260,907	113.6%
Date#inspect	560,483	1,357,800	242.3%
Date#asctime	2,444,606	1,676,951	68.6%
Date#strftime	2,704,672	3,867,297	143.0%
Date#strftime(%Y-%m-%d)	3,051,536	3,252,162	106.6%
Date#strftime(%A %B)	2,911,007	1,725,704	59.3%
Date#strftime(%c)	1,963,184	1,522,719	77.6%
Date#strftime(%x)	2,585,481	2,066,510	79.9%
Date#strftime(composite)	1,581,662	1,880,930	118.9%
Date#iso8601	3,871,147	3,840,760	99.2%
Date#rfc3339	1,787,396	2,382,235	133.3%
Date#rfc2822	1,939,882	1,720,221	88.7%
Date#xmlschema	3,936,023	3,722,464	94.6%
Date#httpdate	1,601,616	1,925,300	120.2%
Date#jisx0301	2,813,683	2,420,539	86.0%
Date#to_date	22,264,202	21,011,318	94.4%
Date#to_datetime	6,826,666	349,452	5.1%
Date#to_time	1,908,133	1,452,386	76.1%
Date#new_start	5,596,668	4,097,288	73.2%
Date#julian	5,827,327	3,818,120	65.5%
Date#gregorian	5,857,213	3,832,377	65.4%
Date#italy	5,237,481	3,860,512	73.7%
Date#england	5,504,857	3,846,989	69.9%
Date Marshal.dump	524,047	586,972	112.0%
Date Marshal.load	562,881	607,496	107.9%
Date#deconstruct_keys(nil)	3,478,812	3,878,040	111.5%
Date#deconstruct_keys(year)	5,298,346	4,469,402	84.4%
Date#deconstruct_keys(y/m/d)	3,919,147	1,841,221	47.0%

DateTime class methods (deprecated — not optimized)

Method	C ext (i/s)	Pure Ruby (i/s)	Ratio
DateTime.civil	1,875,912	351,426	18.7%
DateTime.jd	1,808,918	637,926	35.3%
DateTime.ordinal	1,526,460	601,551	39.4%
DateTime.commercial	1,358,985	352,835	26.0%
DateTime.now	138,945	314,764	226.5%
DateTime.parse(iso)	86,155	35,336	41.0%
DateTime.parse(rfc2822)	75,692	137,568	181.7%
DateTime.strptime	390,524	94,598	24.2%
DateTime.iso8601	332,657	142,625	42.9%
DateTime.rfc3339	360,583	226,296	62.8%
DateTime.rfc2822	284,958	201,992	70.9%
DateTime.xmlschema	354,039	155,424	43.9%
DateTime.httpdate	293,315	214,761	73.2%
DateTime.jisx0301	347,867	150,365	43.2%

DateTime instance methods (deprecated — not optimized)

Method	C ext (i/s)	Pure Ruby (i/s)	Ratio
DateTime#year	20,098,127	15,042,689	74.8%
DateTime#month	21,237,840	16,111,993	75.9%
DateTime#day	18,548,994	16,062,127	86.6%
DateTime#hour	21,333,617	17,826,341	83.6%
DateTime#min	18,521,195	17,755,413	95.9%
DateTime#sec	21,045,565	17,879,183	85.0%
DateTime#sec_fraction	10,109,921	17,794,083	176.0%
DateTime#offset	9,615,641	6,137,640	63.8%
DateTime#zone	3,181,535	1,334,388	41.9%
DateTime#wday	20,440,568	16,914,214	82.7%
DateTime#yday	14,260,455	17,826,177	125.0%
DateTime#jd	19,268,548	20,221,226	104.9%
DateTime#ajd	2,085,063	886,014	42.5%
DateTime#+1	5,377,767	1,662,382	30.9%
DateTime#+frac	281,200	477,164	169.7%
DateTime#-1	3,983,009	1,594,373	40.0%
DateTime#-DT	1,316,729	396,869	30.1%
DateTime#>>1	2,909,249	1,935,724	66.5%
DateTime#<<1	2,128,352	1,829,635	86.0%
DateTime#next_day	5,325,907	1,598,982	30.0%
DateTime#prev_day	3,787,627	1,527,316	40.3%
DateTime#next_month	2,838,329	1,825,383	64.3%
DateTime#prev_month	2,096,188	1,726,255	82.4%
DateTime#next_year	2,627,272	1,701,474	64.8%
DateTime#prev_year	1,963,389	1,616,029	82.3%
DateTime#<=>	12,096,597	7,730,511	63.9%
DateTime#===	11,192,664	6,077,881	54.3%
DateTime#==	2,707,665	9,205,819	340.0%
DateTime#eql?	10,865,195	10,341,655	95.2%
DateTime#hash	13,709,136	7,672,208	56.0%

DateTime formatting / conversion (deprecated — not optimized)

Method	C ext (i/s)	Pure Ruby (i/s)	Ratio
DateTime#to_s	1,892,182	212,119	11.2%
DateTime#inspect	468,910	189,554	40.4%
DateTime#strftime	1,546,127	298,049	19.3%
DateTime#strftime(%Y%m%d%z)	1,680,875	1,006,879	59.9%
DateTime#strftime(%c)	2,063,165	1,035,746	50.2%
DateTime#strftime(%s)	3,244,980	999,168	30.8%
DateTime#iso8601	1,414,142	208,727	14.8%
DateTime#rfc3339	1,308,541	210,804	16.1%
DateTime#rfc2822	1,780,011	1,200,135	67.4%
DateTime#xmlschema	1,415,768	214,005	15.1%
DateTime#httpdate	1,656,273	1,279,407	77.2%
DateTime#jisx0301	1,212,199	467,964	38.6%
DateTime#new_offset(0)	5,246,751	1,157,741	22.1%
DateTime#new_offset(str)	3,408,551	487,457	14.3%
DateTime#new_offset(rat)	2,033,443	1,151,965	56.7%
DateTime#to_date	6,530,329	3,094,153	47.4%
DateTime#to_datetime	22,361,492	21,171,076	94.7%
DateTime#to_time	917,658	680,739	74.2%
DateTime Marshal.dump	532,858	361,435	67.8%
DateTime Marshal.load	551,158	336,273	61.0%
DateTime#deconstruct_keys(nil)	879,547	721,487	82.0%
DateTime#deconstruct_keys(y/h)	4,462,768	2,341,063	52.5%

Time conversion

Method	C ext (i/s)	Pure Ruby (i/s)	Ratio
Time#to_date	3,891,482	1,677,908	43.1%
Time#to_datetime	1,245,844	1,049,600	84.2%

[jeremyevans]

Date was originally written in Ruby prior to Ruby 1.9.3. It was rewritten in C to significantly increase performance. When Date was written in Ruby, it's low performance made it a common bottleneck in Ruby applications. I think for this to be considered, you need to provide comprehensive benchmarks showing that performance does not decrease significantly.

[nobu]

Put # encoding: US-ASCII at the beginning.

[nobu]

A simple benchmark to just create objects:

require'benchmark'require'date'N=10000Benchmark.bmdo |bm|
bm.report("Time"){N.times{Time.now}}bm.report("Date"){N.times{Date.today}}end

With ruby 4.1.0dev (2026-02-14T07:03:18Z master 2065b55980) +PRISM [arm64-darwin25], and master:

$ ruby -I./lib bench.rb user system total realTime 0.001656 0.000023 0.001679 ( 0.001675)Date 0.002735 0.000062 0.002797 ( 0.002827)

This PR:

$ ruby -I./lib bench.rb user system total realTime 0.001018 0.000013 0.001031 ( 0.001031)Date 0.007624 0.000151 0.007775 ( 0.007776)

Interestingly, this PR makes Time.now faster.

[jeremyevans]

@nobu you should probably benchmark with benchmark-driver or benchmark-ips. With a runtime of only ~1ms, it's hard to get statistically valid results. Considering I don't think date modifies the implementation of Time.now, it seems unlikely there would be an significant performance difference.

A benchmark should include most of the methods in the library. When I was working on home_run, I had a set of comprehensive benchmarks to see the differences in performance compared to the (at the time) Ruby implementation. It included a decent set of benchmarks (https://github.com/jeremyevans/home_run/blob/master/bench/cpu_bench.rb), though I would certainly switch the backend to use benchmark-driver or benchmark-ips for this.

[nobu]

For the mean time, just tried Benchmark.ips.

master:

Warming up --------------------------------------
Time.now 206.000 i/100ms
Date.today 46.000 i/100ms
Calculating -------------------------------------
Time.now 2.096k (± 0.1%) i/s (477.11 μs/i) - 10.506k in 5.012541s
Date.today 459.375 (± 0.7%) i/s (2.18 ms/i) - 2.300k in 5.006967s

This PR:

Warming up --------------------------------------
Time.now 206.000 i/100ms
Date.today 16.000 i/100ms
Calculating -------------------------------------
Time.now 2.143k (± 0.6%) i/s (466.72 μs/i) - 10.918k in 5.095787s
Date.today 166.713 (± 0.0%) i/s (6.00 ms/i) - 848.000 in 5.086612s

Agree there seems to be a lot of room for optimization.
The current extension is line-by-line translation from Ruby to C and not optimized for C.
This PR looks also line-by-line in reverse and doubly non-optimal.

[jeremyevans]

The current extension is line-by-line translation from Ruby to C and not optimized for C.

I don't believe the line-by-line translation part is 100% accurate, though it may be true for large portions of the library. The primary implementation difference between the current C implementation and the previous (pre Ruby 1.9.3) Ruby implementation was that the previous Ruby implementation always eagerly converted from whatever the input format was to ajd (e.g. https://github.com/ruby/ruby/blob/ruby_1_9_2/lib/date.rb#L1621-L1629). That's the primary reason it was so slow. home_run pioneered the idea of not converting eagerly to ajd, only doing the conversion later when it was actually needed. That same basic approach was used by tadf when he rewrote date from Ruby to C. See https://bugs.ruby-lang.org/issues/4068 for background on that change.

I think we'd be willing to accept a small performance decrease to switch the C implementation with a Ruby implementation. However, a ~3x performance decrease is way too much to consider switching, IMO. As I mentioned earlier, Date was often a bottleneck in application code before Ruby 1.9.3, that's the reason I worked on home_run. So performance should be a primary consideration when deciding whether to switch to an alternative implementation.

[nobu]

Can you share the benchmark?

As for zonetab.rb, it should be updated like as zonetab.h is automatically updated weekly with ext/date/update-abbr.

[nobu]

Suggested change

	(gmt)\s*\z/ix
	(gmt)\s*\z/ixo

[nobu]

Splitting by \0 comes from the restriction of strftime in C.
It should be unnecessary in Ruby.

[nobu]

Looks too direct C.
format.gsub may be faster, I guess.

result=format.gsub(/(?:%%)+|%([-_^\#0]*)([1-9]\d*)?(?:E[cCxXyY]|O[deHkIlmMSuUVwWy]|[YCymBbhdejHkIlMSLNPpAawuUWVGgZsQntFDxTXRrcv+]|(:{0,3})z)/)do |fmt|
flags,width,spec,colons= $~.capturesnextfmt[0,fmt.length/2]unlessspec# Squeeze '%%' -> '%'spec=spec[-1]ifspec.length > 1# Ignore E / O modifiers

[nobu]

Eventually width is compared with 1024, why need to compare with '2147483647'?

Suggested change

	ifwidth.length > 10 || (width.length == 10 && width > '2147483647')
	ifwidth.length > 4

[nobu]

Ruby's sprintf inherits * flag from C, you don't have to create a new format string each time.

Suggested change

	sprintf("%#{prec}d",y)
	else
	sprintf("%0#{prec}d",y)
	sprintf("%*d",prec,y)
	else
	sprintf("%0*d",prec,y)

[jinroq]

@jeremyevans@nobu

Thank you for your comment! I tried optimizing Ruby implementation of date. The current benchmark results are as follows.

Performance Comparison: C Extension vs Pure Ruby Implementation

Environment: Ruby 4.0.1, measured with benchmark-ips (warmup: 1s, measurement: 2s)
(*) = Pure Ruby is faster than or equal to the C extension.

Method	C ext (i/s)	Ruby (i/s)	Ruby/C
Constructors
Date.civil	4.65 M	1.02 M	21.9%
Date.civil(sg)	4.46 M	1.38 M	31.1%
Date.civil(-1)	4.68 M	994.6 k	21.3%
Date.civil(neg)	4.56 M	1.26 M	27.6%
Date.jd	4.96 M	2.31 M	46.6%
Date.ordinal	3.02 M	947.4 k	31.3%
Date.commercial	2.48 M	809.0 k	32.6%
Date.today	176.9 k	424.0 k	239.6% (*)
Validation
Date.valid_civil?	10.75 M	2.73 M	25.4%
Date.valid_civil?(false)	10.96 M	2.73 M	24.9%
Date.valid_ordinal?	4.23 M	3.89 M	91.9%
Date.valid_commercial?	3.18 M	1.20 M	37.7%
Date.valid_jd?	16.61 M	12.10 M	72.8%
Date.gregorian_leap?	14.91 M	9.42 M	63.2%
Date.gregorian_leap?(1900)	14.71 M	9.03 M	61.4%
Date.julian_leap?	17.20 M	11.81 M	68.7%
Parsing
Date._parse(iso)	232.8 k	61.0 k	26.2%
Date._parse(us)	118.9 k	36.1 k	30.3%
Date._parse(eu)	159.8 k	51.9 k	32.5%
Date._parse(rfc2822)	81.1 k	28.0 k	34.5%
Date.parse(iso)	212.3 k	52.3 k	24.6%
Date.parse(us)	111.5 k	31.9 k	28.6%
Date.parse(eu)	146.8 k	44.7 k	30.4%
Date.parse(compact)	132.0 k	47.2 k	35.8%
Date._strptime	2.72 M	781.8 k	28.7%
Date.strptime	1.37 M	325.9 k	23.7%
Date.strptime(complex)	1.11 M	114.1 k	10.2%
Date._iso8601	723.6 k	464.9 k	64.2%
Date._rfc3339	488.7 k	117.3 k	24.0%
Date._rfc2822	375.8 k	98.9 k	26.3%
Date._xmlschema	766.3 k	551.8 k	72.0%
Date._httpdate	403.5 k	267.2 k	66.2%
Date._jisx0301	713.4 k	538.5 k	75.5%
Date.iso8601	551.8 k	250.6 k	45.4%
Date.rfc3339	396.0 k	100.5 k	25.4%
Date.rfc2822	304.3 k	85.2 k	28.0%
Date.xmlschema	552.7 k	278.4 k	50.4%
Date.httpdate	320.2 k	175.2 k	54.7%
Date.jisx0301	550.4 k	272.4 k	49.5%
Accessors
Date#year	20.24 M	13.27 M	65.6%
Date#month	20.63 M	15.80 M	76.6%
Date#day	18.36 M	15.80 M	86.0%
Date#wday	20.53 M	11.96 M	58.2%
Date#yday	15.60 M	19.10 M	122.4% (*)
Date#jd	19.42 M	16.50 M	85.0%
Date#ajd	7.55 M	4.64 M	61.5%
Date#mjd	11.60 M	8.09 M	69.7%
Date#amjd	10.45 M	5.75 M	55.0%
Date#ld	11.54 M	8.22 M	71.2%
Date#start	20.29 M	20.37 M	100.4% (*)
Date#cwyear	4.49 M	6.81 M	151.5% (*)
Date#cweek	4.56 M	14.65 M	321.5% (*)
Date#cwday	20.34 M	8.58 M	42.2%
Date#leap?	18.67 M	16.74 M	89.7%
Date#julian?	19.40 M	2.68 M	13.8%
Date#gregorian?	19.69 M	2.51 M	12.8%
Weekday predicates
Date#sunday?	20.81 M	9.52 M	45.7%
Date#monday?	20.78 M	9.85 M	47.4%
Date#saturday?	20.79 M	9.80 M	47.1%
Arithmetic
Date#+1	5.89 M	3.46 M	58.7%
Date#+100	5.52 M	3.48 M	63.0%
Date#-1	3.93 M	3.61 M	91.9%
Date#-Date	1.88 M	2.33 M	124.1% (*)
Date#>>1	3.12 M	1.84 M	58.9%
Date#>>12	3.06 M	1.84 M	60.2%
Date#<<1	2.21 M	1.86 M	84.1%
Date#next_day	5.41 M	3.24 M	59.9%
Date#prev_day	3.92 M	3.34 M	85.2%
Date#next_month	3.04 M	1.77 M	58.3%
Date#prev_month	2.21 M	1.75 M	79.3%
Date#next_year	2.74 M	1.69 M	61.7%
Date#prev_year	2.03 M	1.69 M	83.1%
Date#succ	5.57 M	3.05 M	54.7%
Comparison
Date#<=>	11.96 M	3.21 M	26.9%
Date#===	12.54 M	3.13 M	25.0%
Date#==	2.76 M	3.36 M	121.7% (*)
Date#<	7.69 M	3.42 M	44.5%
Date#>	7.93 M	3.41 M	43.0%
Date#eql?	11.34 M	3.37 M	29.7%
Date#hash	13.64 M	7.37 M	54.0%
Iteration
Date#upto(+30)	154.5 k	49.2 k	31.9%
Date#downto(-30)	118.0 k	50.1 k	42.4%
Date#step(+30,7)	804.9 k	242.0 k	30.1%
Formatting / Output
Date#to_s	3.89 M	1.84 M	47.3%
Date#inspect	548.8 k	746.6 k	136.0% (*)
Date#asctime	2.45 M	1.75 M	71.2%
Date#strftime	2.86 M	1.35 M	47.1%
Date#strftime(%Y-%m-%d)	3.14 M	1.54 M	49.2%
Date#strftime(%A %B)	3.11 M	1.31 M	42.1%
Date#strftime(%c)	2.04 M	1.19 M	58.4%
Date#strftime(%x)	2.68 M	1.65 M	61.7%
Date#strftime(composite)	1.67 M	1.46 M	87.1%
Date#iso8601	4.00 M	2.50 M	62.6%
Date#rfc3339	1.90 M	2.24 M	118.2% (*)
Date#rfc2822	1.97 M	1.69 M	85.5%
Date#xmlschema	3.96 M	2.50 M	63.3%
Date#httpdate	1.66 M	1.78 M	106.9% (*)
Date#jisx0301	2.83 M	2.04 M	72.1%
Conversion & Calendar
Date#to_date	22.05 M	21.08 M	95.6%
Date#to_datetime	6.24 M	2.13 M	34.1%
Date#to_time	1.93 M	861.5 k	44.6%
Date#new_start	4.89 M	987.8 k	20.2%
Date#julian	5.78 M	1.19 M	20.6%
Date#gregorian	5.60 M	1.12 M	20.1%
Date#italy	5.76 M	1.18 M	20.4%
Date#england	5.89 M	1.25 M	21.1%
Serialization & Pattern matching
Date Marshal.dump	534.4 k	494.3 k	92.5%
Date Marshal.load	577.2 k	572.9 k	99.3%
Date#deconstruct_keys(nil)	3.62 M	3.07 M	84.8%
Date#deconstruct_keys(year)	5.61 M	2.74 M	48.9%
Date#deconstruct_keys(y/m/d)	3.94 M	1.64 M	41.6%

---

Notes

Methods where pure Ruby equals or exceeds the C extension (*):

• Date.today (239.6%): The C extension pays an extra rb_funcall overhead for Time.now; the Ruby path calls it more directly.
• Date#yday (122.4%), Date#cwyear (151.5%), Date#cweek (321.5%): Results are memoized after the first computation. The C extension recomputes on every call.
• Date#-Date (124.1%), Date#== (121.7%): These are hot-pathed to direct integer arithmetic (@jd subtraction / comparison), avoiding the generalized minus_dd / coercion path used in C.
• Date#rfc3339 (118.2%), Date#httpdate (106.9%), Date#inspect (136.0%): Fast-path string construction added to the Ruby implementation outperforms the C version's general-purpose formatter.
• Date#start (100.4%): Direct @sg ivar read; effectively the same speed.

[jeremyevans]

In the vast majority of cases, the Ruby version is significantly slower than the C extension (2-5x in many cases, with a few cases worse). In the cases where it is faster:

• Date.today could be implemented in Ruby even with the current extension.
• Date.yday, Date.cwyear, Date.cweek could cache this information in the C struct, though I'm not sure whether the memory/CPU tradeoff is worth it, as usage of these methods is not nearly as common as other methods.
• Other cases the performance difference is small, and maybe a similar approach could be used for the C extension to improve performance.

I appreciate that Ruby is easier to maintain than C, but I don't think the performance decrease here is acceptable (or even close to acceptable), considering that Date performance can be a bottleneck in application code.

[jinroq]

@jeremyevans
Further optimizations have been made. Please see the benchmark here.

[jinroq]

@nobu

As for zonetab.rb, it should be updated like as zonetab.h is automatically updated weekly with ext/date/update-abbr.

d276c80 has been fixed.

[jeremyevans]

@jeremyevans Further optimizations have been made. Please see the benchmark here.

The numbers are looking much better. Common actions (Date.civil) are still over 2x slower, though. I don't see benchmarks for Date.new, which I'm guessing is the most common way to instantiate Date objects.

What is ObjectSpace.memsize_of(Date.new) in the new implementation (it's 72 with the current implementation)?

[jinroq]

@jeremyevans

Date.new benchmark (Ruby 4.0.1)

Date.new uses Class#new → initialize, while Date.civil is a direct class method. Here are the benchmark results:

Method	C ext (i/s)	Pure Ruby (i/s)	Ratio
Date.new	3,974,217	1,531,119	38.5%
Date.new(no args)	4,509,731	1,415,434	31.4%

ObjectSpace.memsize_of(Date.new(2024, 1, 1))

Ruby	Implementation	memsize (bytes)
2.6.10	C ext	72
2.7.8	C ext	72
3.0.7	C ext	72
3.1.7	C ext	72
3.2.10	C ext	72
3.3.10	C ext	72
3.3.10	Pure Ruby	80
3.4.8	C ext	72
3.4.8	Pure Ruby	80
4.0.1	C ext	72
4.0.1	Pure Ruby	80

The pure Ruby implementation adds 8 bytes (72 → 80) per Date object. The C extension uses a fixed-size struct, while the pure Ruby version stores
instance variables (@jd, @sg, @df) whose object header accounts for the difference.

[jinroq]

@jeremyevans

I also included benchmarks for Ruby + YJIT, which show sufficient results with YJIT enabled.

Method	C ext (i/s)	Ruby (i/s)	vs C ext	Ruby+YJIT (i/s)	vs C ext
Date.new	4,648,498.9	2,036,150.6	43.8%	6,800,694.4	146.3%
Date.civil	4,648,498.9	2,127,289.0	45.8%	7,054,147.8	151.8%
Date.civil(sg)	4,455,619.7	1,949,044.5	43.7%	6,062,139.0	136.1%
Date.civil(-1)	4,675,053.4	1,626,856.6	34.8%	5,440,817.9	116.4%
Date.civil(neg)	4,563,715.3	1,973,021.1	43.2%	6,551,825.2	143.6%
Date.jd	4,962,000.5	3,534,728.0	71.2%	8,943,396.9	180.2%
Date.ordinal	3,023,006.5	1,888,939.4	62.5%	7,674,517.3	253.9%
Date.commercial	2,478,941.0	1,668,324.9	67.3%	6,896,332.2	278.2%
Date.today	176,946.6	390,025.4	220.4%	485,024.0	274.1%
Date.valid_civil?	10,749,223.3	1,328,167.2	12.4%	6,908,534.8	64.3%
Date.valid_civil?(false)	10,961,294.3	1,762,002.3	16.1%	7,834,300.6	71.5%
Date.valid_ordinal?	4,233,714.4	1,350,027.0	31.9%	6,867,174.2	162.2%
Date.valid_commercial?	3,177,114.9	488,591.4	15.4%	2,387,213.4	75.1%
Date.valid_jd?	16,608,826.2	10,043,032.0	60.5%	24,574,453.1	148.0%
Date.gregorian_leap?	14,913,745.3	6,826,828.2	45.8%	20,989,836.5	140.7%
Date.gregorian_leap?(1900)	14,713,170.5	6,365,132.8	43.3%	20,003,406.2	136.0%
Date.julian_leap?	17,203,164.6	7,938,256.0	46.1%	23,782,084.2	138.2%
Date._parse(iso)	232,827.9	1,294,271.7	555.9%	3,292,066.3	1413.9%
Date._parse(us)	118,925.3	545,573.5	458.8%	661,336.2	556.1%
Date._parse(eu)	159,775.1	475,354.0	297.5%	564,690.0	353.4%
Date._parse(rfc2822)	81,117.7	215,561.9	265.7%	290,587.7	358.2%
Date.parse(iso)	212,254.8	613,834.4	289.2%	1,921,631.3	905.3%
Date.parse(us)	111,533.3	345,410.8	309.7%	542,995.9	486.8%
Date.parse(eu)	146,786.8	309,203.1	210.6%	466,989.1	318.1%
Date.parse(compact)	132,038.9	619,357.0	469.1%	1,981,781.4	1500.9%
Date._strptime	2,721,888.7	1,177,709.3	43.3%	2,147,098.1	78.9%
Date.strptime	1,374,554.3	800,628.7	58.2%	2,014,174.4	146.5%
Date.strptime(complex)	1,114,730.3	338,797.6	30.4%	1,955,386.3	175.4%
Date._iso8601	723,572.8	1,368,965.6	189.2%	4,485,893.6	620.0%
Date._rfc3339	488,706.5	583,054.6	119.3%	2,056,642.5	420.8%
Date._rfc2822	375,804.7	507,272.7	135.0%	1,272,314.2	338.6%
Date._xmlschema	766,287.8	1,367,530.2	178.5%	4,572,233.9	596.7%
Date._httpdate	403,521.7	548,276.9	135.9%	1,247,514.5	309.2%
Date._jisx0301	713,384.0	1,196,125.4	167.7%	2,997,525.2	420.2%
Date.iso8601	551,797.8	627,678.5	113.8%	1,968,689.2	356.8%
Date.rfc3339	395,958.4	384,319.2	97.1%	1,130,586.8	285.5%
Date.rfc2822	304,311.2	342,968.4	112.7%	826,264.6	271.5%
Date.xmlschema	552,686.0	617,598.2	111.7%	2,020,113.2	365.5%
Date.httpdate	320,236.4	363,580.0	113.5%	857,760.5	267.9%
Date.jisx0301	550,356.0	581,997.6	105.7%	1,589,031.8	288.7%
Date#year	20,235,535.8	10,774,110.8	53.2%	27,655,324.0	136.7%
Date#month	20,625,631.9	10,796,911.7	52.3%	28,156,488.9	136.5%
Date#day	18,362,005.8	10,705,688.4	58.3%	27,045,512.4	147.3%
Date#wday	20,530,546.4	11,000,804.2	53.6%	24,403,360.2	118.9%
Date#yday	15,601,172.0	12,876,713.8	82.5%	27,694,425.0	177.5%
Date#jd	19,418,473.5	17,071,262.0	87.9%	29,569,337.8	152.3%
Date#ajd	7,553,399.4	4,298,369.6	56.9%	5,944,814.2	78.7%
Date#mjd	11,597,881.3	17,084,185.2	147.3%	28,895,735.6	249.1%
Date#amjd	10,449,017.7	1,815,580.6	17.4%	2,398,321.6	23.0%
Date#ld	11,537,190.0	16,983,669.5	147.2%	29,047,769.7	251.8%
Date#start	20,286,534.5	17,836,924.1	87.9%	29,304,177.3	144.5%
Date#cwyear	4,493,912.4	16,430,249.9	365.6%	28,214,927.1	627.8%
Date#cweek	4,555,659.7	16,061,004.7	352.6%	28,960,883.3	635.7%
Date#cwday	20,343,305.6	8,371,271.9	41.2%	23,049,924.0	113.3%
Date#leap?	18,667,588.1	8,036,097.5	43.0%	22,004,473.1	117.9%
Date#julian?	19,396,307.1	8,110,830.0	41.8%	23,137,616.8	119.3%
Date#gregorian?	19,689,574.9	9,558,623.9	48.5%	25,319,534.9	128.6%
Date#sunday?	20,810,650.7	9,030,532.6	43.4%	21,230,372.1	102.0%
Date#monday?	20,777,318.6	8,922,244.8	42.9%	23,217,857.0	111.7%
Date#saturday?	20,790,164.4	8,963,911.4	43.1%	23,168,896.6	111.4%
Date#+1	5,893,233.7	2,889,182.8	49.0%	5,040,998.6	85.5%
Date#+100	5,520,702.9	2,937,903.5	53.2%	5,033,091.2	91.2%
Date#-1	3,929,555.6	2,597,216.7	66.1%	5,340,599.7	135.9%
Date#-Date	1,875,155.2	1,972,961.1	105.2%	3,117,628.6	166.3%
Date#>>1	3,119,218.3	1,613,270.3	51.7%	4,226,230.4	135.5%
Date#>>12	3,061,617.7	1,631,701.9	53.3%	4,189,177.5	136.8%
Date#<<1	2,206,893.6	1,547,786.7	70.1%	4,157,267.8	188.4%
Date#next_day	5,407,206.0	2,700,424.4	49.9%	4,981,497.3	92.1%
Date#prev_day	3,923,672.9	2,535,334.7	64.6%	4,917,461.8	125.3%
Date#next_month	3,038,007.5	1,574,504.9	51.8%	4,099,210.9	134.9%
Date#prev_month	2,207,619.7	1,497,764.9	67.8%	4,114,609.8	186.4%
Date#next_year	2,736,947.8	1,566,210.4	57.2%	4,085,857.7	149.3%
Date#prev_year	2,028,662.2	1,417,257.9	69.9%	4,171,630.4	205.6%
Date#succ	5,569,330.6	2,717,558.2	48.8%	5,286,740.7	94.9%
Date#<=>	11,961,484.4	6,609,541.3	55.3%	21,053,740.7	176.0%
Date#===	12,543,036.5	5,541,720.8	44.2%	19,983,408.5	159.3%
Date#==	2,760,650.4	7,322,420.6	265.2%	22,861,312.3	828.1%
Date#<	7,685,771.4	6,455,497.0	84.0%	20,481,215.1	266.5%
Date#>	7,929,852.6	6,473,788.7	81.6%	21,216,662.3	267.6%
Date#eql?	11,335,321.9	7,930,323.2	70.0%	24,341,834.0	214.7%
Date#hash	13,639,648.1	10,546,833.3	77.3%	16,202,422.0	118.8%
Date#upto(+30)	154,548.8	134,861.8	87.3%	236,819.6	153.2%
Date#downto(-30)	118,018.3	132,404.6	112.2%	243,172.5	206.0%
Date#step(+30,7)	804,863.4	687,218.2	85.4%	1,316,888.1	163.6%
Date#to_s	3,889,377.7	3,769,828.9	96.9%	6,604,270.8	169.8%
Date#inspect	548,810.9	1,187,608.2	216.4%	1,706,568.4	311.0%
Date#asctime	2,452,656.1	1,505,310.9	61.4%	2,201,277.9	89.8%
Date#strftime	2,863,406.8	3,332,272.9	116.4%	6,691,922.9	233.7%
Date#strftime(%Y-%m-%d)	3,138,482.2	2,817,965.7	89.8%	4,125,145.7	131.4%
Date#strftime(%A %B)	3,109,861.1	1,553,015.9	49.9%	2,028,742.3	65.2%
Date#strftime(%c)	2,041,797.7	1,323,864.4	64.8%	1,765,369.8	86.5%
Date#strftime(%x)	2,676,711.2	1,903,867.7	71.1%	2,382,801.7	89.0%
Date#strftime(composite)	1,671,366.5	1,613,957.3	96.6%	2,224,556.5	133.1%
Date#iso8601	3,999,850.6	3,450,501.3	86.3%	6,286,520.0	157.2%
Date#rfc3339	1,896,360.7	2,111,494.2	111.3%	3,381,402.3	178.3%
Date#rfc2822	1,974,373.5	1,593,782.9	80.7%	2,289,653.2	116.0%
Date#xmlschema	3,955,976.0	3,500,299.9	88.5%	6,337,757.0	160.2%
Date#httpdate	1,663,870.8	1,779,108.2	106.9%	2,700,540.9	162.3%
Date#jisx0301	2,833,069.0	2,351,477.2	83.0%	3,091,380.4	109.1%
Date#to_date	22,050,815.1	18,402,764.7	83.5%	31,789,222.2	144.2%
Date#to_datetime	6,244,339.9	296,676.2	4.8%	715,839.5	11.5%
Date#to_time	1,933,709.8	471,209.1	24.4%	539,343.5	27.9%
Date#new_start	4,889,348.6	3,343,094.7	68.4%	4,996,316.0	102.2%
Date#julian	5,778,390.6	3,171,427.1	54.9%	4,960,678.0	85.8%
Date#gregorian	5,599,171.9	3,188,930.4	57.0%	4,961,054.6	88.6%
Date#italy	5,762,239.8	3,251,144.1	56.4%	5,045,699.5	87.6%
Date#england	5,893,742.2	3,233,278.2	54.9%	4,987,572.9	84.6%
Date Marshal.dump	534,350.2	545,965.0	102.2%	583,518.2	109.2%
Date Marshal.load	577,187.8	563,082.5	97.6%	626,781.8	108.6%
Date#deconstruct_keys(nil)	3,618,972.7	3,023,491.2	83.5%	4,757,871.6	131.5%
Date#deconstruct_keys(year)	5,607,895.3	3,859,001.1	68.8%	6,029,250.7	107.5%
Date#deconstruct_keys(y/m/d)	3,942,984.9	1,667,445.0	42.3%	3,673,872.7	93.2%
DateTime.civil	1,851,893.5	313,100.2	16.9%	720,137.6	38.9%
DateTime.jd	1,889,075.3	554,991.0	29.4%	1,067,002.2	56.5%
DateTime.ordinal	1,508,769.7	536,343.4	35.5%	1,514,865.1	100.4%
DateTime.commercial	1,351,171.4	311,674.3	23.1%	1,106,892.2	81.9%
DateTime.now	139,518.4	287,473.0	206.0%	365,739.0	262.1%
DateTime.parse(iso)	84,713.9	33,538.6	39.6%	48,763.1	57.6%
DateTime.parse(rfc2822)	74,627.0	121,937.2	163.4%	209,317.4	280.5%
DateTime.strptime	394,530.9	81,962.5	20.8%	309,988.4	78.6%
DateTime.iso8601	355,014.9	127,652.6	36.0%	246,696.0	69.5%
DateTime.rfc3339	379,544.4	204,046.4	53.8%	616,887.1	162.5%
DateTime.rfc2822	284,987.5	180,603.6	63.4%	467,337.6	164.0%
DateTime.xmlschema	358,991.2	142,858.9	39.8%	259,931.0	72.4%
DateTime.httpdate	298,051.0	196,967.1	66.1%	500,106.0	167.8%
DateTime.jisx0301	345,210.8	132,675.8	38.4%	256,861.4	74.4%
DateTime#year	19,881,470.7	11,071,056.1	55.7%	26,023,439.7	130.9%
DateTime#month	20,924,763.4	12,215,448.7	58.4%	25,207,601.2	120.5%
DateTime#day	18,785,995.5	12,171,972.8	64.8%	25,542,575.0	136.0%
DateTime#hour	21,502,513.9	12,824,548.2	59.6%	28,950,420.8	134.6%
DateTime#min	18,485,836.5	12,626,620.6	68.3%	28,900,737.2	156.3%
DateTime#sec	20,797,882.5	12,742,817.0	61.3%	29,335,953.4	141.1%
DateTime#sec_fraction	10,200,271.9	12,706,458.8	124.6%	29,223,527.0	286.5%
DateTime#offset	9,829,985.5	5,084,467.5	51.7%	6,634,926.1	67.5%
DateTime#zone	3,207,822.5	1,182,995.5	36.9%	1,448,983.9	45.2%
DateTime#wday	20,168,567.7	15,619,425.4	77.4%	24,279,235.7	120.4%
DateTime#yday	14,700,414.1	12,912,832.2	87.8%	25,935,006.8	176.4%
DateTime#jd	19,103,691.9	17,924,629.0	93.8%	21,115,737.4	110.5%
DateTime#ajd	2,100,589.4	757,860.4	36.1%	969,689.3	46.2%
DateTime#+1	5,385,075.7	1,477,393.3	27.4%	4,128,308.8	76.7%
DateTime#+frac	292,699.0	427,903.8	146.2%	705,517.6	241.0%
DateTime#-1	4,006,702.8	1,402,167.4	35.0%	3,811,043.9	95.1%
DateTime#-DT	1,316,024.9	335,266.8	25.5%	480,147.5	36.5%
DateTime#>>1	2,915,200.6	1,573,828.7	54.0%	3,767,400.8	129.2%
DateTime#<<1	2,091,904.2	1,534,607.3	73.4%	3,659,443.7	174.9%
DateTime#next_day	5,282,096.7	1,440,511.1	27.3%	4,050,846.1	76.7%
DateTime#prev_day	3,924,083.2	1,375,942.9	35.1%	3,960,172.7	100.9%
DateTime#next_month	2,789,292.9	1,532,713.4	54.9%	3,670,986.2	131.6%
DateTime#prev_month	2,052,433.3	1,445,021.4	70.4%	3,661,189.0	178.4%
DateTime#next_year	2,672,709.2	1,508,662.3	56.4%	3,683,351.2	137.8%
DateTime#prev_year	1,970,385.2	1,408,942.8	71.5%	3,720,693.5	188.8%
DateTime#<=>	12,133,082.2	6,597,448.7	54.4%	19,160,491.0	157.9%
DateTime#===	11,302,900.6	4,964,157.5	43.9%	16,864,706.3	149.2%
DateTime#==	2,746,062.5	7,161,663.6	260.8%	20,932,614.6	762.3%
DateTime#eql?	11,282,592.6	7,817,051.7	69.3%	24,241,577.9	214.9%
DateTime#hash	13,883,068.1	6,540,332.4	47.1%	12,099,219.7	87.2%
DateTime#to_s	1,940,594.7	192,016.1	9.9%	484,311.3	25.0%
DateTime#inspect	470,005.4	169,330.0	36.0%	386,114.9	82.2%
DateTime#strftime	1,531,900.0	273,764.3	17.9%	537,769.3	35.1%
DateTime#strftime(%Y%m%d%z)	1,681,470.3	898,867.1	53.5%	1,371,085.3	81.5%
DateTime#strftime(%c)	1,998,483.9	944,923.6	47.3%	1,277,656.4	63.9%
DateTime#strftime(%s)	3,244,638.4	896,356.5	27.6%	1,782,512.8	54.9%
DateTime#iso8601	1,367,474.5	191,089.6	14.0%	491,047.4	35.9%
DateTime#rfc3339	1,374,890.5	191,139.4	13.9%	500,719.3	36.4%
DateTime#rfc2822	1,905,864.7	1,093,096.5	57.4%	1,637,555.2	85.9%
DateTime#xmlschema	1,380,004.6	195,651.5	14.2%	497,945.6	36.1%
DateTime#httpdate	1,666,736.7	1,181,090.2	70.9%	1,772,252.2	106.3%
DateTime#jisx0301	1,184,511.6	425,241.9	35.9%	531,411.1	44.9%
DateTime#new_offset(0)	5,652,278.9	1,014,871.0	18.0%	2,707,830.8	47.9%
DateTime#new_offset(str)	3,782,946.8	422,249.2	11.2%	758,318.2	20.0%
DateTime#new_offset(rat)	2,332,643.4	989,378.9	42.4%	2,375,151.0	101.8%
DateTime#to_date	6,722,539.6	2,827,305.6	42.1%	7,816,381.4	116.3%
DateTime#to_datetime	21,865,006.0	18,708,595.0	85.6%	31,341,332.2	143.3%
DateTime#to_time	910,402.1	594,570.5	65.3%	1,092,081.2	120.0%
DateTime Marshal.dump	529,753.9	335,623.4	63.4%	359,797.7	67.9%
DateTime Marshal.load	563,611.5	310,872.2	55.2%	345,545.9	61.3%
DateTime#deconstruct_keys(nil)	901,133.5	606,273.5	67.3%	708,956.3	78.7%
DateTime#deconstruct_keys(y/h)	4,464,776.5	2,094,465.9	46.9%	4,119,094.4	92.3%
Time#to_date	3,868,352.1	1,509,377.0	39.0%	5,625,967.0	145.4%
Time#to_datetime	1,216,319.1	964,642.1	79.3%	2,239,412.0	184.1%

[jeremyevans]

I hadn't realized the earlier benchmark numbers were without YJIT. Anyway who cares about performance is going to enable YJIT, and as the numbers with YJIT are overall significantly faster, I don't see any barriers to merging this. Thank you very much for your work on this.

[jinroq]

@nobu@jeremyevans

Replace all getbyte-based byte manipulation with StringScanner and regex patterns for improved readability and maintainability.
In exchange, the performance of Date._strptime and Date.strptime has decreased. Please give us your feedback on this.

Benchmark	C ext+YJIT	pure Ruby+YJIT	Ratio
Date._strptime	2,263,815	1,284,553	57%
Date.strptime	1,156,519	1,189,801	103%
Date.strptime(complex)	905,983	424,281	47%

Here are benchmarks for all Date methods:

Method	C ext	C ext+YJIT	pure Ruby	pure Ruby+YJIT	Ruby+YJIT vs C+YJIT
Date.new	3.6M	4.5M	1.8M	5.7M	129%
Date.civil	3.8M	3.7M	1.6M	5.5M	147%
Date.civil(sg)	3.0M	3.2M	1.7M	5.2M	162%
Date.civil(-1)	3.4M	4.2M	1.6M	4.7M	110%
Date.civil(neg)	3.4M	4.0M	1.6M	5.9M	147%
Date.jd	3.4M	4.1M	3.0M	7.4M	181%
Date.ordinal	2.3M	2.5M	1.7M	6.7M	263%
Date.commercial	2.0M	2.2M	1.5M	5.9M	265%
Date.today	335.1k	343.5k	430.2k	472.7k	138%
Date.valid_civil?	8.4M	10.7M	1.2M	6.1M	57%
Date.valid_civil?(false)	8.3M	12.5M	1.6M	7.0M	56%
Date.valid_ordinal?	3.5M	4.0M	1.3M	6.2M	152%
Date.valid_commercial?	2.8M	3.0M	435.2k	2.1M	71%
Date.valid_jd?	12.7M	19.6M	8.7M	20.5M	104%
Date.gregorian_leap?	11.7M	19.4M	5.9M	15.4M	79%
Date.gregorian_leap?(1900)	11.7M	19.7M	5.7M	17.3M	88%
Date.julian_leap?	11.3M	19.5M	7.2M	20.2M	104%
Date._parse(iso)	182.9k	191.6k	461.4k	546.6k	285%
Date._parse(us)	92.6k	96.1k	449.9k	566.0k	589%
Date._parse(eu)	120.5k	123.1k	403.2k	491.5k	399%
Date._parse(rfc2822)	60.3k	60.0k	142.7k	165.9k	276%
Date.parse(iso)	162.8k	165.3k	300.3k	490.4k	297%
Date.parse(us)	87.1k	87.6k	293.7k	467.0k	533%
Date.parse(eu)	113.6k	114.4k	267.9k	409.9k	358%
Date.parse(compact)	104.4k	106.2k	290.8k	457.5k	431%
Date._strptime	2.2M	2.3M	860.4k	1.3M	57%
Date.strptime	1.1M	1.2M	614.1k	1.2M	103%
Date.strptime(complex)	921.1k	906.0k	254.7k	424.3k	47%
Date._iso8601	534.1k	575.7k	462.8k	578.6k	100%
Date._rfc3339	388.4k	385.2k	190.5k	308.9k	80%
Date._rfc2822	265.2k	221.9k	153.2k	232.5k	105%
Date._xmlschema	560.4k	514.9k	379.7k	438.9k	85%
Date._httpdate	245.4k	237.5k	170.4k	211.0k	89%
Date._jisx0301	376.2k	470.2k	315.8k	383.7k	82%
Date.iso8601	410.8k	404.9k	258.3k	439.5k	109%
Date.rfc3339	304.0k	267.7k	167.7k	228.1k	85%
Date.rfc2822	209.6k	162.9k	119.9k	194.9k	120%
Date.xmlschema	351.0k	299.3k	227.3k	366.8k	123%
Date.httpdate	208.7k	168.2k	121.0k	207.7k	123%
Date.jisx0301	299.5k	342.6k	234.8k	329.2k	96%
Date#year	9.9M	14.6M	7.0M	18.0M	124%
Date#month	9.8M	15.7M	8.4M	15.8M	101%
Date#day	11.3M	19.4M	7.4M	13.1M	67%
Date#wday	13.6M	15.7M	8.2M	15.2M	97%
Date#yday	7.7M	14.3M	11.3M	17.6M	122%
Date#jd	11.3M	16.7M	12.9M	22.7M	136%
Date#ajd	4.7M	6.3M	3.6M	5.0M	78%
Date#mjd	8.1M	8.7M	14.3M	24.1M	277%
Date#amjd	5.7M	7.6M	1.6M	2.2M	29%
Date#ld	7.9M	11.5M	14.9M	24.2M	210%
Date#start	15.4M	23.0M	15.2M	25.0M	108%
Date#cwyear	3.8M	4.3M	15.0M	25.0M	589%
Date#cweek	3.9M	4.2M	14.6M	24.5M	577%
Date#cwday	15.6M	23.4M	7.5M	18.4M	79%
Date#leap?	12.1M	16.8M	7.2M	19.5M	116%
Date#julian?	13.1M	21.0M	7.4M	19.7M	94%
Date#gregorian?	13.1M	18.9M	7.9M	20.7M	109%
Date#sunday?	15.1M	20.2M	6.9M	16.4M	81%
Date#monday?	13.7M	17.7M	7.2M	17.1M	97%
Date#saturday?	12.0M	18.9M	7.7M	14.0M	74%
Date#+1	4.9M	5.7M	2.4M	3.9M	69%
Date#+100	4.7M	5.4M	2.4M	4.4M	81%
Date#-1	3.1M	3.6M	2.3M	4.1M	113%
Date#-Date	1.5M	1.5M	1.8M	2.9M	187%
Date#>>1	2.5M	2.6M	1.4M	3.2M	123%
Date#>>12	2.4M	2.3M	1.5M	3.6M	154%
Date#<<1	1.7M	1.9M	1.3M	3.4M	184%
Date#next_day	4.8M	5.8M	2.3M	4.2M	73%
Date#prev_day	3.4M	3.7M	2.2M	4.3M	115%
Date#next_month	2.5M	2.6M	1.3M	3.5M	136%
Date#prev_month	1.7M	1.7M	1.3M	3.5M	208%
Date#next_year	2.1M	2.4M	1.4M	3.7M	152%
Date#prev_year	1.6M	1.8M	1.3M	3.4M	193%
Date#succ	5.1M	6.1M	2.4M	4.6M	75%
Date#<=>	8.1M	10.9M	5.8M	19.1M	175%
Date#===	8.3M	12.9M	5.0M	17.2M	133%
Date#==	2.2M	2.4M	6.6M	20.8M	851%
Date#<	6.0M	7.0M	5.9M	14.8M	210%
Date#>	6.0M	7.1M	5.9M	18.9M	265%
Date#eql?	8.0M	10.5M	7.2M	21.8M	207%
Date#hash	10.3M	16.8M	9.6M	14.8M	88%
Date#upto(+30)	134.1k	139.9k	112.8k	184.6k	132%
Date#downto(-30)	95.9k	99.0k	116.7k	194.0k	196%
Date#step(+30,7)	684.4k	781.9k	610.1k	1.1M	145%
Date#to_s	3.1M	3.4M	3.4M	6.1M	180%
Date#inspect	486.5k	495.3k	1.1M	1.6M	320%
Date#asctime	1.9M	2.0M	1.3M	2.0M	99%
Date#strftime	2.4M	2.6M	3.1M	6.1M	235%
Date#strftime(%Y-%m-%d)	2.6M	2.8M	2.6M	3.8M	133%
Date#strftime(%A %B)	2.4M	2.6M	1.1M	1.7M	64%
Date#strftime(%c)	1.3M	1.6M	864.8k	1.5M	93%
Date#strftime(%x)	1.5M	2.3M	1.7M	2.2M	94%
Date#strftime(composite)	1.4M	1.3M	1.5M	2.0M	152%
Date#iso8601	2.8M	3.5M	3.3M	6.0M	172%
Date#rfc3339	1.5M	1.6M	2.0M	3.2M	203%
Date#rfc2822	1.6M	1.6M	1.5M	2.1M	129%
Date#xmlschema	3.1M	3.4M	3.2M	5.9M	172%
Date#httpdate	1.3M	1.3M	1.7M	2.3M	173%
Date#jisx0301	2.2M	2.5M	2.1M	2.8M	115%
Date#to_date	17.0M	25.8M	16.2M	17.4M	67%
Date#to_datetime	5.8M	5.5M	272.0k	652.0k	12%
Date#to_time	471.9k	441.7k	427.6k	483.9k	110%
Date#new_start	4.9M	5.7M	2.8M	4.0M	70%
Date#julian	5.2M	5.9M	2.7M	3.9M	67%
Date#gregorian	5.3M	5.9M	2.7M	3.8M	65%
Date#italy	5.1M	6.4M	2.7M	3.9M	62%
Date#england	5.2M	6.1M	2.8M	4.3M	71%
Date Marshal.dump	461.3k	457.4k	485.4k	531.5k	116%
Date Marshal.load	496.3k	489.1k	493.4k	559.2k	114%
Date#deconstruct_keys(nil)	2.6M	2.7M	2.5M	3.4M	127%
Date#deconstruct_keys(year)	3.6M	3.8M	3.2M	4.8M	126%
Date#deconstruct_keys(y/m/d)	2.8M	3.0M	1.4M	2.5M	82%
DateTime.civil	1.4M	1.6M	266.5k	620.5k	40%
DateTime.jd	1.5M	1.6M	487.9k	834.8k	51%
DateTime.ordinal	1.2M	1.3M	438.4k	1.4M	111%
DateTime.commercial	1.0M	1.2M	294.5k	1.0M	85%
DateTime.now	243.9k	251.4k	314.2k	351.6k	140%
DateTime.parse(iso)	69.4k	69.0k	28.1k	40.0k	58%
DateTime.parse(rfc2822)	57.8k	59.9k	91.2k	141.4k	236%
DateTime.strptime	311.7k	309.3k	36.1k	54.2k	18%
DateTime.iso8601	294.2k	291.6k	96.1k	155.3k	53%
DateTime.rfc3339	304.2k	312.4k	126.1k	204.3k	65%
DateTime.rfc2822	211.0k	208.7k	107.6k	180.1k	86%
DateTime.xmlschema	282.7k	288.6k	87.3k	148.3k	51%
DateTime.httpdate	208.3k	214.0k	116.0k	184.9k	86%
DateTime.jisx0301	259.6k	233.7k	92.2k	156.4k	67%
DateTime#year	13.4M	21.6M	10.0M	17.7M	82%
DateTime#month	13.0M	24.7M	11.3M	22.2M	90%
DateTime#day	16.0M	24.6M	11.0M	20.9M	85%
DateTime#hour	16.0M	22.9M	11.4M	18.9M	83%
DateTime#min	15.8M	22.8M	11.2M	24.9M	110%
DateTime#sec	15.5M	24.1M	11.4M	23.3M	96%
DateTime#sec_fraction	7.7M	9.6M	10.9M	22.9M	237%
DateTime#offset	5.8M	9.1M	4.5M	6.6M	73%
DateTime#zone	2.5M	2.8M	1.0M	1.3M	46%
DateTime#wday	14.3M	20.2M	13.1M	19.5M	97%
DateTime#yday	10.3M	14.4M	11.3M	19.3M	134%
DateTime#jd	13.4M	18.4M	13.5M	22.0M	120%
DateTime#ajd	1.5M	1.7M	638.8k	916.6k	54%
DateTime#+1	5.3M	6.0M	1.3M	3.8M	63%
DateTime#+frac	236.9k	247.4k	359.4k	640.7k	259%
DateTime#-1	3.5M	3.2M	1.2M	3.5M	111%
DateTime#-DT	1.1M	1.1M	320.8k	451.8k	41%
DateTime#>>1	2.6M	2.7M	1.5M	3.5M	130%
DateTime#<<1	1.8M	1.9M	1.4M	3.3M	176%
DateTime#next_day	5.3M	5.9M	1.3M	3.4M	58%
DateTime#prev_day	3.6M	3.8M	1.2M	3.5M	91%
DateTime#next_month	2.5M	2.6M	1.4M	3.5M	133%
DateTime#prev_month	1.8M	1.9M	1.4M	3.3M	169%
DateTime#next_year	2.3M	2.4M	1.4M	3.2M	135%
DateTime#prev_year	1.7M	1.7M	1.3M	3.5M	200%
DateTime#<=>	9.7M	11.5M	6.2M	16.9M	147%
DateTime#===	8.3M	11.0M	4.6M	16.4M	149%
DateTime#==	2.4M	2.6M	6.7M	18.5M	715%
DateTime#eql?	8.8M	10.8M	7.3M	21.9M	203%
DateTime#hash	10.5M	16.7M	6.2M	11.3M	67%
DateTime#to_s	1.6M	1.6M	88.5k	121.5k	7%
DateTime#inspect	428.9k	398.6k	63.8k	115.4k	29%
DateTime#strftime	1.3M	1.2M	134.9k	181.7k	15%
DateTime#strftime(%Y%m%d%z)	1.4M	1.5M	796.5k	1.3M	88%
DateTime#strftime(%c)	1.7M	1.8M	832.8k	1.2M	68%
DateTime#strftime(%s)	2.7M	3.0M	455.0k	590.7k	20%
DateTime#iso8601	1.1M	1.2M	85.9k	121.5k	10%
DateTime#rfc3339	1.1M	1.2M	86.2k	119.6k	10%
DateTime#rfc2822	1.5M	1.6M	992.8k	1.5M	96%
DateTime#xmlschema	1.2M	1.2M	86.6k	120.7k	10%
DateTime#httpdate	1.3M	1.4M	1.1M	1.7M	119%
DateTime#jisx0301	1.0M	1.1M	394.3k	496.0k	47%
DateTime#new_offset(0)	4.9M	6.0M	922.9k	2.4M	40%
DateTime#new_offset(str)	3.7M	3.9M	356.0k	572.8k	15%
DateTime#new_offset(rat)	2.0M	1.6M	943.9k	2.1M	128%
DateTime#to_date	5.7M	5.6M	2.7M	7.0M	126%
DateTime#to_datetime	10.9M	17.3M	17.0M	29.6M	172%
DateTime#to_time	588.6k	721.2k	554.6k	997.2k	138%
DateTime Marshal.dump	463.1k	463.7k	310.5k	324.9k	70%
DateTime Marshal.load	488.9k	487.0k	291.2k	328.3k	67%
DateTime#deconstruct_keys(nil)	761.7k	688.3k	528.7k	598.2k	87%
DateTime#deconstruct_keys(y/h)	3.4M	3.6M	1.9M	3.6M	99%
Time#to_date	3.3M	3.6M	1.4M	5.2M	144%
Time#to_datetime	1.1M	1.0M	983.7k	2.2M	209%

[rhenium]

Although I haven't worked on date and am unfamiliar with it, I think we should be cautious about the amount of code inlining/duplication in this patch. This particular fragment is duplicated more than 10 times, whereas it appeared only once in the C implementation (c_civil_to_jd() in date_core.c, I think).

More generally, I worry that a mechanical conversion combined with this kind of micro-optimization may make the codebase less maintainable for humans.

[jinroq]

@rhenium
Thank you for your feedback. As you pointed out, we were over-optimizing by inlining. 7e80db9 has reduced inlining.

[jeremyevans]

Replace all getbyte-based byte manipulation with StringScanner and regex patterns for improved readability and maintainability.
In exchange, the performance of Date._strptime and Date.strptime has decreased. Please give us your feedback on this.

In general, getbyte-style optimizations should be used sparingly. If we are going to convert from C to Ruby, we should be converting to idiomatic Ruby as much as possible. The decrease looks pretty substantial, though. Maybe I should do a review of the code and see how maintainable the Ruby code actually looks.

More pressing is the issue that @rhenium mentioned about duplicated code. We want to make sure the Ruby code is as well factored as the C code, or at least close. Duplicating code from a method and inlining it into every caller location is not good.

[nobu]

No need to strip, as eval skips leading/trailing spaces.

Suggested change

offset_expr.strip!

[nobu]

Suggested change

	sorted = entries.sort_by { |k, _| k }
	sorted = entries.sort

[nobu]

Both sides look the same expression.

Suggested change

	key = abbr.include?(' ') ? %Q("#{abbr}") : %Q("#{abbr}")
	f.puts " %-#{max_key_len + 3}s => %d," % [key, offset]
	f.printf " %-*p => %d,\n", max_key_len + 3, abbr, offset

[nobu]

Suggested change

	File.foreach(list_path) do |line|
	line.chomp!
	File.foreach(list_path, chomp: true) do |line|

[nobu]

Suggested change

	in_entries = false
	File.foreach(list_path) do |line|
	line.chomp!
	if line == '%%'
	if in_entries
	break
	else
	in_entries = true
	next
	end
	end
	next unless in_entries
	sections = 0
	File.foreach(list_path) do |line|
	line.chomp!
	break if line == '%%' and (sections += 1) > 1
	next if sections < 1

[nobu]

Suggested change

	f.puts '# Auto-generated from ext/date/zonetab.list by ext/date/generate-zonetab-rb.'
	f.puts "# Auto-generated from #{list_path} by ext/date/generate-zonetab-rb."

[nobu]

Suggested change

	b=s.bytes
	((b[0] | 0x20) << 16) | ((b[1] | 0x20) << 8) | (b[2] | 0x20)
	b0,b1,b2=s.unpack("C3")
	((b0 | 0x20) << 16) | ((b1 | 0x20) << 8) | (b2 | 0x20)

[jinroq]

Thanks for the suggestion. s.unpack("C3") is functionally equivalent here, and I agree it expresses the "exactly 3 bytes" intent more clearly. However, compute_3key is called from the hot parsing loops in parse.rb and strptime.rb, so I benchmarked it under YJIT:

method	ips
bytes (current)	8.26M i/s
unpack C3	4.08M i/s - 2.03x slower

unpack("C3") is about 2x slower than the current s.bytes (the format-string handling has noticeable overhead), so on this hot path I'd prefer to keep s.bytes. The results are otherwise identical — I verified equivalence over the actual day/month abbreviations and all 17,576 lowercase 3-letter combinations.

[byroot]

If you are micro-optimizing, you might want to try:

b0,b1,b2=s.getbyte(0),s.getbyte(1),s.getbyte(2)

It should save the array allocation, and also YJIT has codegen for String#getbyte.

[byroot]

# frozen_string_literal: truerequire'benchmark/ips's="ABC"Benchmark.ipsdo |x|
x.report("bytes")dob=s.bytes((b[0] | 0x20) << 16) | ((b[1] | 0x20) << 8) | (b[2] | 0x20)endx.report("unpack")dob0,b1,b2=s.unpack("C3")((b0 | 0x20) << 16) | ((b1 | 0x20) << 8) | (b2 | 0x20)endx.report("getbyte")do((s.getbyte(0) | 0x20) << 16) | ((s.getbyte(1) | 0x20) << 8) | (s.getbyte(2) | 0x20)endx.compare!(order: :baseline)end

ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +YJIT +PRISM [arm64-darwin25]
Warming up --------------------------------------
bytes 1.649M i/100ms
unpack 1.189M i/100ms
getbyte 4.452M i/100ms
Calculating -------------------------------------
bytes 18.127M (± 0.6%) i/s (55.17 ns/i) - 90.679M in 5.002478s
unpack 12.623M (± 0.6%) i/s (79.22 ns/i) - 64.189M in 5.084961s
getbyte 52.338M (± 0.4%) i/s (19.11 ns/i) - 262.667M in 5.018661s
Comparison:
bytes: 18126826.3 i/s
getbyte: 52338075.0 i/s - 2.89x faster
unpack: 12623204.8 i/s - 1.44x slower

[jinroq]

I understand the usefulness of getbyte, but I avoided it because I overused it in the past, leading to poor maintainability.

@nobu
What do you think?

[nobu]

I intended just that the rest of the bytes would be wasted.

[eregon]

Since you're getting the byte value here anyway getbyte seems perfectly fine and the right method for this

[jinroq]

@byroot@eregon

After talking with nobu, I decided to use getbyte.

[nobu]

Shouldn't use Date.compute_3key consistently?

[nobu]

This file looks unused.

[nobu]

Some constants seem to be used more locally.
For instance, HAVE_* and FL_* are used only in a method.

[jeremyevans]

I had some time tonight, so I checked lib/date/core.rb to see if the issues discussed in my previous comment (#155 (comment)) were addressed.

Use of Kernel#Integer for conversion: still present, but only after check_numeric calls, and those raise TypeError for non-numeric input. So the issue is fixed. I think it would be simpler to rename check_numeric to convert_numeric_to_int and have it use Kernel#Integer to convert the value and return that. So instead of:

check_numeric(jd,"jd")jd=Integer(jd)

You would have:

jd=convert_numeric_to_int(jd,"jd")

The following debugging methods from the C extension were removed from the Ruby code, so that issue is fixed:

• Date.weeknum
• Date.nth_kday
• Date.new!
• Date#nth_kday?
• Date.weeknum_to_jd
• Date.nth_kday_to_jd

Explicit call-seqs are still present in the documentation. I suppose it is fine to keep them.

Considering that with YJIT, the Ruby code is faster than the C extension, losing the lazy initialization optimization doesn't seem like a blocker. We can always add it back in a later PR.

That being said, it does seem unnecessarily wasteful for Date.new/Date.civil to not pass the year/month/day to the created instance. I recommend renaming init_from_jd to initialize. I would change it to accept year/month/day as arguments, and pass the appropriate arguments from other methods if they are available. By allowing it to take year/month/day, you can simplify initialize_copy by having it call initialize (then you don't need to worry about the instance variable order being out of sync).

Date.new still calls Date.civil instead of being an alias, same with Date#iso8601 calling Date#to_s instead of being an alias. Both of these should be fixed.

Date#initialize is no longer present. The implementation still uses allocate and init_from_jd, when it could be simplified by aliasing new to new! and making it private (assuming the rename of init_from_jd to initialize as described above).

Date#yday, Date#cweek, and Date#cwyear no longer cache, so that is fixed.

Date#day_fraction now returns integer and not rational, so that is fixed.

Date#<, Date#> and Date#== were removed, and the implementation now uses the Comparable methods, so that is fixed.

Date#deconstruct_keys now calls methods instead of inling the related code, so that is fixed. If the Ruby code only targets Ruby 3.3+, we could use implicit hash values ({year:}) to make this a bit simpler.

@sg was renamed to @start, and @df to @day_fraction, so that is fixed.

The existing C extension does support a Date instance with a fractional day component. However, it's pretty bad as the day fraction isn't even used if you convert the instance to a DateTime

date=Date.jd(2461234.5)date.jd# => 2461234date.day_fraction# => (1/2)date.to_datetime.day_fraction# => (0/1)

I think we should drop fractional day support for Date, and only support fractional days for DateTime. I would remove @day_fraction completely from the Date implementation, and have Date#day_fraction always return 0. DateTime can use @day_fraction and have DateTime#day_fraction be an attr_reader method. Existing use of @day_fraction inside Date should switch to day_fraction.

Unlike the C extension, the Ruby library doesn't split a fractional input jd into an integer jd and day fraction, so it already doesn't match the C extension behavior in this regard. I would disallow the use of fractional days for Date (only allow for DateTime), raising an exception if a fractional day is used as input.

If we do want to support fractional days for Date, then you need to mirror the C extension's handling of fractional days in input. I think dropping fractional days for Date, while backwards incompatible, is acceptable, as I'm guessing we will do a major version bump if replacing the C extension with the Ruby library.

I still think we shop drop the C extension and bump required_ruby_version to 3.3 (or the minimum Ruby version that passes the tests).

I'm not sure how @nobu, @rhenium, @byroot, and @eregon feel about dropping the C extension or how they feel about dropping support for fractional days for Date, so I'm interested in hearing their opinions.

I plan to start review of files other than lib/date/core.rb on July 15.

[rhenium]

If we can get better performance without sacrificing maintainability, that's great! Thank you for the effort to make this work and to review the changes.

My main concern is maintenance since ruby/date is fairly complex, and especially since it currently doesn't have a designated maintainer. Some parts of this PR appear to be fairly direct ports from C, such as use of bitmasks in parse.rb and strftime.rb (though that's not the only example). The code is frankly rather difficult to navigate and I think some refactoring work is wanted.

Dropping support for Ruby < 3.3 seems reasonable since Ruby 3.2 reached EOL on 2026-04. I suspect the Ruby implementation could be made compatible with older versions with few changes, but that's completely optional and may not be worth the extra work.

Dropping support for fractional days on Date also makes sense to me. Date.new is another method working inconsistently by silently truncating it (though this looks like a bug - add_frac() can't work in #initialize:

date/ext/date/date_core.c

Line 3750 in f61aa49

add_frac();

). I don't have any insight into the original design, but hopefully no one is relying on the partial support we currently have.

[rhenium]

These constants are documented. The rdoc comments should be kept here:

date/ext/date/date_core.c

Lines 9789 to 9792 in f61aa49

	/* An array of strings of full month names in English. The first
	* element is nil.
	*/
	rb_define_const(cDate, "MONTHNAMES", mk_ary_of_str(13, monthnames));

[rhenium]

I don't think this error exists in the C implementation.

[rhenium]

This method returns a UTF-8 string.

Perhaps we can change the source encoding instead of repeating force_encoding?

[rhenium]

Whether the code matches the old C implementation or not isn't particularly useful information for future readers, and such comments will likely become stale, so I suggest documenting the actual purpose instead.

[jeremyevans]

I continued my review today. I will continue reviewing this weekend.

date.rb:

Other than requires, the code is a copy from existing date.rb, so definitely compatible. No issues.

date/version.rb:

New file, but only code is copied from previous date.rb. No issues.

date/shared.rb:

New file adding Date.compute_3key. This appears to be used for month/day name maps, I would guess as an optimization. What is the performance benefit of this optimization? This optimization is new, since the previous code used a simple array iteration in C (the equivalent of an Array#find_index approach in Ruby). The code would certainly be easier to understand if the 3 byte string was used as a hash key, so I assume there is a performance benefit, but I'm not sure how much.

date/constants.rb:

The DEFAULT_SG constant is copied from a C #define, but I don't think it makes much sense to have a private constant for this. I would replace all instances of DEFAULT_SG with ITALY and then remove DEFAULT_SG.

As mentioned above, we should consider whether the performance benefits of the compute_3key approach are worth the extra complexity. Similarly, how much performance benefit is there from using an integer key as opposed to a single character string key in STRFTIME_COMPOSITE_BYTE? Similar questions for STRFTIME_E_VALID_BYTES and STRFTIME_O_VALID_BYTES.

ASCTIME_DAYS and ASCTIME_MONS are duplicates of ABBR_DAYNAMES and ABBR_MONTHNAMES and should be removed. Additionally, the following constant aliases should be removed:

• RFC2822_DAYS
• STRFTIME_MONTHS_FULL
• STRFTIME_MONTHS_ABBR
• STRFTIME_DAYS_FULL
• STRFTIME_DAYS_ABBR

Is the performance benefit of MONTH_DAY_SUFFIX really worth the complexity, compared to a plain array with [nil, "01", "02", ...], that you could use for both month and day lookups? Similar question:

• ASCTIME_PREFIX
• RFC_MON_SPACE
• DAY_FULL_COMMA
• MONTH_FULL_SPACE

I'm not sure it's worth having constants for all default argument values. With frozen strings, it's unlikely to provide better performance. It's more self documenting if the strings are used directly. Using a constant does ensure the value is the same if multiple methods use the same value, but I think the self documentation benefits outweigh that. This applies to:

• JULIAN_EPOCH_DATE
• JULIAN_EPOCH_DATETIME
• JULIAN_EPOCH_DATETIME_RFC2822
• JULIAN_EPOCH_DATETIME_HTTPDATE
• DEFAULT_STRFTIME_FMT
• YMD_FMT

I think we should reduce STRFTIME_MAX_WIDTH by a lot. 65535 width seems crazy to allow. 21 width would allow the ability for the entire 64-bit number range.

STRFTIME_MAX_COPY_LEN is used to raise an exception if the date's year, expressed as a string, is more than 1024 bytes. However, this is raised after you've already generated the resulting string, so it's not like it saves an expensive calculation. I would remove this check and constant. Especially since the limit isn't enforced in all cases, such as in strftime("%A, %B %d, %Y")

HTTPDATE_WDAY uses string keys instead of a compute_3key approach. This seems inconsistent.

The regexp constants that use month and day names or abbreviations (e.g. HTTPDATE_TYPE1_RE) may benefit from a local variable interpolation, so you aren't repeating the names in every regexp that uses them.

date/time.rb:

Time#to_date should use the standard constructor (Date.new(year, mon, mday)).

For Time#to_datetime, it's less clear cut, because the standard constructor would require: DateTime.new(year, mon, mday, hour, min, sec + subsec, utc_offset/86400r), which could have a significant negative effect on performance. However, it's worth benchmarking, because if the performance hit isn't significant, I would use the standard constructor.

date/strftime.rb:

Optimizing strftime for the no-argument case isn't worth doing, as almost all usage is with an argument. The case optimizes %Y-%m-%d but not the equivalent %F. Again, there is rarely a reason to do this, as if you want %Y-%m-%d, it's simpler to call to_s or iso8601. I would remove the fast paths. Especially since internal_strftime already does the same optimization for both %Y-%m-%d and %F in the first case statement.

internal_strftime has multiple instance_of?(Date) calls. We may want to use an approach where Date#strftime only handles Date and doesn't attempt to handle DateTime, and have DateTime#strftime to handle any time-specific formatting.

All fast paths at the top of internal_strftime (before StringScanner) are dubious and can give the impression that the code is optimized for specific benchmarks. For common format strings, there often exists an existing method that uses that format, in which case it is simpler to use that method than call strftime. Benchmarks should be provided for the non-fast paths.

In scan loop, the code scans for colons both before and after scanning for flags, and adds the number of colons together. This seems wrong, and deviates from current behavior:

d=Date.today.strftime("%:10z")# Current: "%:10z"# With PR: "+000000:00"

Additionally, behavior differs if more than 3 colons are provided with the z modifier:

d=Date.today.strftime("%::::z")# Current: "%::::z"# With PR: "+00:00"

I stopped my review at line 128 of date/strftime.rb.

[jeremyevans]

I reviewed all remaining code that I had not previously reviewed.

date/strftime.rb:

Behavior with locale O and E modifiers can differ in certain cases:

Date.today.strftime("%10OY")# Current: "%10OY"# With PR: "%OY"Date.today.strftime("%1Em")# Current: "%1Em"# With PR: "%Em"Date.today.strftime("%:Em")# Current: "%:Em"# With PR: "%Em"

The C extension checks that the E and O modifiers are only valid for certain formats (E: cCxXyY, O: deHkIlmMSuUVwWy). The Ruby code appears to attempt to implement this check in format_spec_b, but if the spec isn't valid for the modifier, it uses only the locale modifier and format, which doesn't include length/colon modifier given in the format string.

I think the parser needs to be reworked so that it checks for valid modifiers during the parsing (instead of waiting for a later step), or it keeps a string of all modifiers so it can restore all of them.

The Ruby code appears to contain hallucinated support for both a width and a precision separated with a period. The C strftime pattern parser does not contain a '.' literal, and I can find no documentation that a precision for a width is supported. I can only guess AI halluccinated the support because strftime is somewhat similar in nature to snprintf (which supports a precision for a width), and the C extension uses precision in the source code for the strftime support, just in a different context.

Date.today.strftime("%1.2m")# Current: "%1.2m"# With PR: "7"

Padding for width modifiers is in some cases handled differently in the C extension than in the Ruby code:

Date.today.strftime("%4u")# Current: "0006"# With PR: " 6"

Flag order in modifiers is respected in the C extension but not in the Ruby code:

Date.today.strftime("%0_m")# Current: " 7"# With PR: " 7"Date.today.strftime("%_0m")# Current: "07"# With PR: " 7"

I would guess there are a lot of differences between the C extension Date#strftime and the Ruby Date#strftime. To ensure that behavior is the same, before merging the Ruby library, we should generate additional C extension strftime tests for every format specifer (50) with an assertion for every combination of modifier types (2**5 flags combinations, multiple widths {1,10}, 0-4 colons, 2 local modifiers), for both Date and DateTime. This is a lot of additional assertions (64000), but they should run quickly.

For fmt_asctime_str, could lookup the day of month string in an array instead of the d < 10 ? " #{d}" : d.to_s approach. Could also be used for the e format specifier. The w specifier could use a similar lookup array. This would be similar to PAD2, but with space padding instead of zero padding, and probably only needs to go up to 31 instead of 99.

For fast_spec, there are a lot of internal_civil unless @year calls. I would remove these and instead call the related methods (year, month, day), which would simplify a lot of this code.

The use of the byte integer instead of single character string for the case in fast_spec and format_spec_b is a bit of a smell. How much does it actually optimize the method? I'm fairly sure it's not worth using a byte integer for the locale modifier.

In which cases does fast_spec fall through to format_spec_b, and in which cases does format_spec_b use the fallback "%#{spec&.chr}"?

The + format specifier seems like it should be in STRFTIME_COMPOSITE_BYTE, so it doesn't need its own when.

In fmt_year, probably can avoid some String#+ calls if the receiver would be an empty string. Additionally, the year should always be numeric, so it looks like the final if/else is unnecessary, and the method should just return s.

In fmt_str, since the method has s = s.dup at the top, it can probably use downcase! or upcase! to save allocations.

In fmt_z, there is a lot of duplication between the lead/no_lead cases, it would be simpler to combine them.

date/strptime.rb:

For Date._strptime/Date.strptime, the fast paths for certain formats look like benchmark optimization. In general, if you have a known format that is handled by an existing method, you would use that instead of strptime. For example, %F/%Y-%m-%d are handled by Date._iso8601/Date.iso8601. I'm not sure why the %a %b %d %Y string is optimized, when the more common %a, %d %b %Y (used for httpdate, rfc822, rfc2822) is not. I searched the ruby/ruby repository for %a %b %d %Y and got no results.

Error handling for invalid types does not match the C extension:

Date._strptime(:foo, "%z")
Current: no implicit conversion of Symbol into String (TypeError)
With PR: undefined method 'to_str' for an instance of Symbol (NoMethodError)

Methods starting with internalinternal_ should probably be changed to start with internal_.

Regexp constants only used in a single place should be inlined.

Unlike the strftime handling, colon and locale modifiers appear to be appropriately restricted in strptime.

Similar to strftime, I'd like to see how much improvement the byte integer based case statement brings over the single character string approach.

Seems like strptime could also use STRFTIME_COMPOSITE_BYTE in most cases (maybe not 118/v), to DRY up some redundant when branches. If not directly, it can use a similar approach with a STRPTIME_COMPOSITE_BYTE constant.

There is a lot of code of the type that should be extracted into a method:

throw(:sp_fail)unlesssn=s.to_ithrow(:sp_fail)ifn < lower_bound || n > upper_boundhash[symbol]=n

There is redundant code for sign checks, in one of two forms, either:

ifstr_sc.scan(SP_SIGN)sign=str_sc.matched == '-' ? -1 : 1elsesign=1end

or:

sign=1ifstr_sc.skip(/-/)sign= -1end

I would standardize on an approach (the second approach looks simpler) and extract it into a method.

In some cases where sign checks are used, it does the equivalent of n = sign * n (sign being 1 or -1) and in other cases it uses n = -n if sign == -1. Again, better to standardize on an approach here.

In internal_strptime_ymd, assuming we keep the method, better to combine the STRPTIME_YMD_EXACT and STRPTIME_YMD_PREFIX code, since it's the same other than the leftover handling. The STRPTIME_YMD_GENERAL can avoid a capture group for the rest of the string by removing the (.*)\z from the regexp and using m.post_match to get the leftover. In internalinternal_strptime_ymd_to_date, code after the year/mon/mday is the same. The method should be refactored so that code is shared, assuming we want to keep the method. If we did want to keep these methods, there should be one method that handles parsing and returns or yields the year/month/day/leftover, instead of duplicating the logic. Similar issue for internal_strptime_abdy and internalinternal_strptime_abdy_to_date.

In sp_zone_to_diff, strip_word doesn't appear to need to be a closure. I would make it a constant or a method. Many cases here could probably use mutating string methods instead of string methods that return modified copies. t[$&.length..] seems like it could be $' (or switch to a less cryptic approach using match and post_match).

In sp_complete_frags, we should have a method that accepts a hash and an array of keys, and returns how many keys are present in the hash. This would allow DRYing up a lot of the code.

date/parse.rb:

Handling of non-string types does not match the C extension:

Date.rfc3339(:foo)
Current: invalid date (Date::Error)
With PR: TypeError (TypeError)
Date._rfc3339(:foo)
Current: => {}
With PR: TypeError (TypeError)
Date.rfc3339(Object.new)
Current: no implicit conversion of Object into String (TypeError)
With PR: undefined method 'to_str' for an instance of Object (NoMethodError)
Date._rfc3339(Object.new)
Current: no implicit conversion of Object into String (TypeError)
With PR: undefined method 'to_str' for an instance of Object (NoMethodError)

This appears to be true for other methods, so all should be checked and behavior updated to match the C extension. We should add a method for all of this code, which appears in multiple methods (after fixing the code to match the C extension behavior):

unlessString === stringraiseTypeErrorifstring.is_a?(Symbol)return{}ifstring.nil?string=string.to_strendreturn{}ifstring.empty?raiseArgumentError,"string length (#{string.length}) exceeds the limit #{limit}"iflimit && string.length > limit

The Ruby library has a method for the limit check in parse_check_limit, but it is never called. Similar, it has a method for converting objects to string (parse_to_str), but that is also not called.

For the underscore parsing methods (e.g. _rfc3339, _httpdate), how much performance benefit is there from having fast paths? If it isn't substantial, we may want to skip the fast paths.

In Ruby 4.1+, you can use MatchData#integer_at to speed up a lot of conversions (probably also in strptime handling as well). Not sure whether it is worth adding a method like matchdata_integer_at(matchdata, i) that uses matchdata.integer_at(i) on Ruby 4.1 and matchdata[i].to_i on older Ruby versions.

In _rfc2822, there is this code: zone = '+0000' if zone == '+0000', which I assume is unnecessary and can be deleted.

In _xmlschema and _iso8601, the fast path uses a StringScanner instead of an approach using match? and indexing into the string, which is used in internal_strptime_ymd in date/strptime.rb. These should should the same approach, whichever one is faster. There seems to be significant usage of StringScanner in multiple methods that could be handled by Regexp#match, since the StringScanner instance only has scan called on it once.

In _parse, instead of using a bitmap for cc, I would use boolean local variables. So:

if !matched && (cc & (HAVE_ALPHA | HAVE_DIGIT)) == (HAVE_ALPHA | HAVE_DIGIT)

would become:

if !matched && (have_alpha || have_digit)

I think you could avoid repeated have_digit checks by restructuring:

ifhave_digit# parse checks from parse_time to parse_yearend

It would be simpler to have _parse call a method that did the parsing from parse_eu to parse_ddd, so once a match was found, the method could return, instead of having every branch use if !matched &&.

There is a lot of code of the form:

h[:hour]=m[x].to_iifm[x]h[:min]=m[x+1].to_iifm[x+1]h[:sec]=m[x+2].to_iifm[x+2]h[:sec_fraction]=parse_sec_fraction(m[x+3])ifm[x+3]parse_zone_and_offset(m[x+4],h)ifm[x+4]

I would add a method for this, accepting h, m, and x and convert other methods to use it.

There is a significant amount of code using:

str[m.begin(0)...m.end(0)]=' ' * (m.end(0) - m.begin(0))

A slightly faster approach avoids range allocation:

e=m.end(0)b=m.begin(0)size=e - bstr[b,size]=" " * size

I would add a method for that approach and call it from the other places.

The matched local variable seems to only be used in boolean context, and a number of else; false branches could be removed if matched could contain nil instead of false.

In parse_ddd, the following lines show up in multiple sequential branches:

off_s="+#{off_s}"unlessoff_s.start_with?('+') || off_s.start_with?('-')h[:offset]=fast_zone_offset(off_s)

The code should be refactored so this occurs after the branches using if off_s, avoiding the duplication.

In s3e, ys_raw[$~.end(0)..] can be $' (or again, use Regexp#match and MatchData#post_match for less cryptic code). There is duplicate code in steps 2, 4, and 5 of the type that should probably be extracted into a method:

s2=s1.sub(/\A'?-?/,'').sub(/(?:st|nd|rd|th)\z/i,'')ifs2.length > 2 || s1.start_with?("'")

Similarly, there is also redundant code of the type for determining the comp flag that should be extracted into a method (also in s3eparse_year):

(num_s.start_with?('-') || num_s.start_with?('+') || num_s.sub(/\A[-+]/,'').length > 2)

date/zonetab.rb:

This is an autogenerated file. I only checked a few hash keys/values, but I assume the rest are correct. If we are dropping support for the C extension, we should remove ext/date/zonetab.list, move ext/date/update-abbr somewhere outside ext (possibly inline the code into the Rakefile), and have it generate lib/date/zonetab.rb directly instead of generating ext/date/zonetab.list.

date/datetime.rb:

Inline the STRFTIME_DATETIME_DEFAULT_FMT constant into the one place it is used and remove it. Same for the DATETIME_TO_S_FMT constant.

DateTime#initialize accepts non-numeric year and month, which the C extension doesn't support:

DateTime.new("2000")Current: invalidyear(not numeric)(TypeError)WithPR: =>#<DateTime: 2000-01-01T00:00:00+00:00 ((2451545j,0s,0n),+0s,2299161j)>DateTime.new(2000,"10")Current: invalidmonth(not numeric)(TypeError)WithPR: =>#<DateTime: 2000-10-01T00:00:00+00:00 ((2451819j,0s,0n),+0s,2299161j)>

It also accepts arguments after a fractional argument for day, hour, or minute, which the C extension doesn't support:

DateTime.new(2000,1,1.5,1)Current: invalidfraction(Date::Error)WithPR: =>#<DateTime: 2000-01-01T13:00:00+00:00 ((2451545j,46800s,0n),+0s,2299161j)>

Invalid offsets appear to be ignored in the C extension, but respected in the Ruby code:

DateTime.new(2000,2,3,4,5,6, -30)Current: =>#<DateTime: 2000-02-03T04:05:06+00:00 ((2451578j,14706s,0n),+0s,2299161j)>WithPR: =>#<DateTime: 2000-02-03T04:05:06-720:00 ((2451608j,14706s,0n),-2592000s,2299161j)>

Other constructors appear have these issues: DateTime.jd, DateTime.ordinal, DateTime.commercial. Some of these may have their own conversion issues, such as:

DateTime.jd(1,2,3,'6')Current: invalidsecond(not numeric)(TypeError)WithPR: =>#<DateTime: -4712-01-02T02:03:06+00:00 ((1j,7386s,0n),+0s,2299161j)>

As mentioned for Date, we should not throw away the known hour/minute/second in DateTime#initialize, we should ensure it is set correctly for the created object, so it doesn't need to recalculate it from the jd.

hour and min should be attr_readers. I recommend renaming @sec_i to @sec and @sec_frac to @sec_fraction, so sec and sec_fraction can be attr_readers as well.

@day_fraction is set to nil by _init_datetime, but it is never used. day_fraction recalculates it every time. It's probably worth caching by changing day_fraction to use @day_fraction ||=.

ajd should call offset and day_fraction instead of duplicating the logic.

+ should have the Numeric case do self + r after checking that r is Rational, instead of duplicating the logic. The logic in _from_total_sec_r can then be inlined, since that is the only caller.

- can probably treat Integer arguments the same as Rational and Float arguments.

For multiple methods, there are existing call-seq documentation issues, such as d.new_offset([offset=0]) should be d.new_offset(offset = 0) (the = makes it optional, no need for brackets). Probably fine to leave for now, but we should address at some point.

Multiple methods appear to convert arguments to integer in cases where the C extension would raise a TypeError:

DateTime.now.jisx0301("1")Current: noimplicitconversionofStringintoInteger(TypeError)WithPR: =>"R08.07.19T20:12:59.5-07:00"DateTime.now.iso8601("1")Current: noimplicitconversionofStringintoInteger(TypeError)WithPR: =>"2026-07-19T20:14:56.7-07:00"

It's a bit strange that #jisx0301 doesn't use #strftime, and that #iso8601 calculates the fractional seconds manually instead of using %#{n}N in the format string (which would result in simpler code).

Marshalling DateTime does not appear to work between the C extension and the Ruby code, looks like the offset is not set correctly on the loaded instance (happens to work if the offset is 0). The Ruby code doesn't load the offset from the C extension marshal dump, and the C extension doesn't load the offset from the Ruby code marshal dump.

# C extensiondt=DateTime.now# => #<DateTime: 2026-07-19T20:28:25-07:00 ((2461242j,12505s,882676146n),-25200s,2299161j)>s=Marshal.dumpdt# => "\x04\bU:\rDateTime[\vi\x00i\x03:\x8E%i\x02\xD90i\x04\xB2\x91\x9C4i\xFE\x90\x9Df\f2299161"dt2=dt.new_offset(0)# => #<DateTime: 2026-07-20T03:28:25+00:00 ((2461242j,12505s,882676146n),+0s,2299161j)>s2=Marshal.dumpdt2# => "\x04\bU:\rDateTime[\vi\x00i\x03:\x8E%i\x02\xD90i\x04\xB2\x91\x9C4i\x00f\f2299161"# Ruby libMarshal.load(s)# => #<DateTime: 2026-07-20T03:28:25-07:00 ((2461242j,37705s,882676146n),-25200s,2299161j)>Marshal.load(s2)# => #<DateTime: 2026-07-20T03:28:25+00:00 ((2461242j,12505s,882676146n),+0s,2299161j)>

To find issues like this, we should run Marshal.dump with Date and DateTime objects for a number of historical Ruby releases, and add tests for all unique results, that check that Marshal.load results in the expect value. Ideally, it would be best if we had tests that Marshal.dump for the same Date and DateTime resulted in the specific expected string, as that should ensure both backwards and forwards compatibility.

DateTime.new is defined to call allocate and then initialize, which seems to duplicate Class#new. I would remove the method definition.

DateTime._strptime requires an argument in the C extension but not in the Ruby code. If you call the method without the string, you get a NameError, because the default value is an undefined constant reference. The default value for the first argument should be removed. DateTime.strptime has the same issue, except that in the C extension, the method has a default value, so the default value in the Ruby code should be changed from JULIAN_EPOCH_DATETIME to Date::JULIAN_EPOCH_DATETIME (or better yet, just inline the value). Note that the reason that this constant lookup doesn't work is that constant lookup only looks in superclasses of the current namespace, not superclasses of containing namespaces. The current namespace in this case is the singleton class of DateTime, not DateTime itself, so it doesn't find the constant defined in Date.

Not sure whether we should fix this, but marshal_load returns self in the C extension and nil in the Ruby code.

In _parse_of, the Rational and Numeric branches of the case expression are the same. As Rational is a subclass of Numeric, I would remove the Rational branch.

_split_sec and _split_second have the same definition, but one is public and the other is private. At the least, one should be an alias of the other, but unless there is a good reason, everything should call the same method. Same with zone and zone_str (pick one and inline _of2str).

The private methods that just return instance variable values should be attr_reader methods or aliases of them.

Overall comments:

We should add coverage testing and ensure 100% line/branch coverage before merging.

[jinroq]

@jeremyevans

Thank you for the review!

I have a couple of things I'd like to check with you.

1. DateTime is already deprecated. Should we still address the issues you pointed out for DateTime?
2. I'm also thinking of deprecating Date#to_datetime. What are your thoughts on this?

[jeremyevans]

@jeremyevans

Thank you for the review!

I have a couple of things I'd like to check with you.

1. DateTime is already deprecated. Should we still address the issues you pointed out for DateTime?

For any issues I pointed out where the behavior is not backwards compatible, the issue must be addressed before merging. I guess the other issues are not necessarily blockers, but most of those are easy to implement so it would be a good idea to address those as well. We don't need to optimize DateTime to the same extent as Date.

2. I'm also thinking of deprecating Date#to_datetime. What are your thoughts on this?

If we want to deprecate it in the same way that DateTime is deprecated (documentation only), I think that's fine. Actual deprecation warnings should probably come at a later stage, and be consistent for all cases where a DateTime instance is created or DateTime is referenced. Possibly Object.deprecate_constant :DateTime will be sufficient for that.

[eregon]

I'm not sure how @nobu, @rhenium, @byroot, and @eregon feel about dropping the C extension or how they feel about dropping support for fractional days for Date, so I'm interested in hearing their opinions.

+1 to both.
Maintaining both C and Ruby impls would be very difficult.
I don't think fractional days makes sense for Date, it's supposed to designate a given date/day.

[eregon]

1. DateTime is already deprecated. Should we still address the issues you pointed out for DateTime?

I would say it's more encouraging to use Time when possible since that's core. It's saying considered deprecated which IOW is please use Time instead where possible.
But in fact they have a significant difference: Time doesn't handle different calendars and so is imprecise when using dates far in the past or future. Time is timestamp-based (i.e. basically incorrect for anything < 1600), Date/DateTime is conceptually ajd-based so can be fully accurate.