Why is DateTime 36 bytes?

[tyt2y3]

std::mem::size_of::<jiff::civil::DateTime>() = 36;
std::mem::size_of::<chrono::DateTime<chrono::FixedOffset>>() = 16;

in comparison chrono::DateTime is just 16 bytes.

std::mem::size_of::<jiff::Timestamp>() = 40;
std::mem::size_of::<jiff::Zoned>() = 96;

Timestamp is also quite big for what can be represented with u128, but Zoned is even bigger.

Why is that?

[BurntSushi]

Are you compiling jiff in debug mode or release mode? Please provide an MRE.

[tyt2y3]

numbers posted above was debug mode. here it is in release mode on 1.86

std::mem::size_of::<jiff::civil::DateTime>() = 12
std::mem::size_of::<jiff::Timestamp>() = 16
std::mem::size_of::<jiff::Zoned>() = 40

this is interesting .. unless you did something specfic to padding / alignment based on build mode? normally they don't differ this much

[BurntSushi]

It is intentional. Debug mode uses ranged integers to track min and max runtime values to ensure correctness. This requires extra space that is only use in debug mode.

[tyt2y3]

can this be turned off by --no-default-features?

[BurntSushi]

Also, chrono::DateTime is not the same as civil::DateTime. So it's an inappropriate comparison. The former is an instant in time. The latter is a civil datetime.

[BurntSushi]

can this be turned off by --no-default-features?

No. It can only be turned off by disabling debug assertions. I don't know why you would though. It's debug mode.

[tyt2y3]

well, we wrap values inside Value enum, and 96 bytes is a large difference to the smallest variant (8 bytes).
we may end up having to box the large variants.