`ZonedDateTime` allocates memory when using disambiguating method with `Bool`s (but not with `Int`s)

[giordano]

julia> using TimeZones

julia> @time ZonedDateTime(2025, 7, 18, 22, 5, tz"Europe/Berlin")
  0.000002 seconds
2025-07-18T22:05:00+02:00

julia> @time ZonedDateTime(2025, 7, 18, 22, 5, tz"Europe/Berlin", 1)
  0.000002 seconds
2025-07-18T22:05:00+02:00

julia> @time ZonedDateTime(2025, 7, 18, 22, 5, tz"Europe/Berlin", true)
  0.000001 seconds (1 allocation: 48 bytes)
2025-07-18T22:05:00+02:00

The last method allocates memory. It'd be nice to remove the memory allocation, since the other ones don't have it

[giordano]

Gentle bump. Some help with debugging would be appreciated. Very confusingly,

julia> @which ZonedDateTime(2025, 7, 18, 22, 5, tz"Europe/Berlin", true)
ZonedDateTime(y::Integer, m::Integer, d::Integer, h::Integer, mi::Integer, tz::VariableTimeZone, amb::Integer)
     @ TimeZones none:0

doesn't return anything useful, so I have no clue of where to look at in the code. How's this method defined?

[giordano]

Ok, I think that comes from

TimeZones.jl/src/types/zoneddatetime.jl

Lines 116 to 118 in 4d5f314

	@optional function ZonedDateTime(y::Integer, m::Integer=1, d::Integer=1, h::Integer=0, mi::Integer=0, s::Integer=0, ms::Integer=0, tz::VariableTimeZone, amb::Union{Integer,Bool})
	ZonedDateTime(DateTime(y,m,d,h,mi,s,ms), tz, amb)
	end

and the macro is messing up with the method location. So now we need to follow the culprit at

julia> @benchmark ZonedDateTime($(DateTime(2025, 7, 18, 22, 5)), tz"Europe/Berlin", true)
BenchmarkTools.Trial: 10000 samples with 993 evaluations per sample.
 Range (min … max):  34.575 ns …  10.396 μs  ┊ GC (min … max): 0.00% … 99.47%
 Time  (median):     35.415 ns               ┊ GC (median):    0.00%
 Time  (mean ± σ):   38.883 ns ± 126.479 ns  ┊ GC (mean ± σ):  7.20% ±  2.60%

      ▅▄█▂▃               ▁
  ▁▄▆██████▆▃▃▂▂▂▂▂▂▂▂▁▁▂▄██▄▄▂▃▂▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁ ▂
  34.6 ns         Histogram: frequency by time         41.2 ns <

 Memory estimate: 48 bytes, allocs estimate: 1.

julia> @which ZonedDateTime((DateTime(2025, 7, 18, 22, 5)), tz"Europe/Berlin", true)
ZonedDateTime(dt::DateTime, tz::VariableTimeZone, is_dst::Bool)
     @ TimeZones ~/.julia/packages/TimeZones/dt27j/src/types/zoneddatetime.jl:86

I presume the allocation is

TimeZones.jl/src/types/zoneddatetime.jl

Line 95 in 4d5f314

mask = [isdst(zdt.zone.offset) for zdt in possible]

?

[giordano]

Yeah, as far as I understand now, the allocation is coming from the branch

TimeZones.jl/src/types/zoneddatetime.jl

Lines 94 to 101 in 4d5f314

	elseif num == 2
	mask = [isdst(zdt.zone.offset) for zdt in possible]
	# Mask is expected to be unambiguous.
	!xor(mask...) && throw(AmbiguousTimeError(dt, tz))
	occurrence = findfirst(d -> d == is_dst, mask)
	return possible[occurrence]

even if that's not entered (I think indexing possible allocates?), but I'm missing what exactly causes the memory allocation.

[giordano]

Making mask a tuple instead of a BitVector doesn't seem to help:

diff --git a/src/types/zoneddatetime.jl b/src/types/zoneddatetime.jl
index 5191f830..f4b5f9e1 100644
--- a/src/types/zoneddatetime.jl
+++ b/src/types/zoneddatetime.jl
@@ -92,12 +92,12 @@ function ZonedDateTime(dt::DateTime, tz::VariableTimeZone, is_dst::Bool)
     elseif num == 0
         throw(NonExistentTimeError(dt, tz))
     elseif num == 2
-        mask = [isdst(zdt.zone.offset) for zdt in possible]
+        mask = TimeZones.isdst.((possible[1].zone.offset, possible[2].zone.offset))
 
         # Mask is expected to be unambiguous.
-        !xor(mask...) && throw(AmbiguousTimeError(dt, tz))
+        !xor(mask[1], mask[2]) && throw(TimeZones.AmbiguousTimeError(dt, tz))
 
-        occurrence = findfirst(d -> d == is_dst, mask)
+        occurrence = findfirst(==(is_dst), mask)::Int
         return possible[occurrence]
     else
         throw(AmbiguousTimeError(dt, tz))

I'm quite puzzled, in that branch there's still a memory allocation which eludes me. @code_warntype ZonedDateTime(DateTime(2025, 10, 26, 2, 5), tz"Europe/Berlin", true) doesn't show significant type instabilities.