This crate can be made no-std and no-alloc

[AaronKutch]

Hello, this crate is nearly perfect for my usecase, except that it appears to be unnecessarily dependent on std. From a quick scan of the crate, std is only actually needed for SystemTime. I would recommend making your own error enum with thiserror so that you can get rid of anyhow, and then using alloc::String for any strings. Furthermore, it should be possible to make the crate usefully no-alloc by gating anything with strings behind an "alloc" feature, and adding a variation of as_iso_datetime that takes a mutable slice of bytes and uses str::from_utf8_mut to return a &mut str. This would make the crate usable anywhere. There aren't any no-alloc datetime crates as far as I am aware.

[AaronKutch]

Is there a known maximum possible size in bytes for ISO datetime for a given precisions? If so, you could expose a constant function that I could use for the input array size.

[poshcoe]

Hi, I'm glad to see this crate get some use!

This was my first crate and it has some foibles as you've found out. I have been using it internally for other projects but since it is getting some interest I will do a comb through and clean things up further.

I agree with making the crate no-alloc and implementing a custom error type. IIRC you're correct about string related functions being unnecessarily gated behind the std dependency. I'll look into fixing these for a 0.3 release.

Is there a known maximum possible size in bytes for ISO datetime for a given precisions? If so, you could expose a constant function that I could use for the input array size.

ISO date-time strings can have varying precision, but if this precision was specified with a const generic or similar then this should be possible without too much change to the API. Would this fit your use case?

[AaronKutch]

Thanks!

ISO date-time strings can have varying precision, but if this precision was specified with a const generic or similar then this should be possible without too much change to the API. Would this fit your use case?

This would be needed if the ISO function would be infallible, but I was thinking that it should simply check that an input slice had the needed length otherwise it would return an error.

[poshcoe]

Hi @AaronKutch, I've opened #10 as the 0.3.0 PR. Let me know if you have any feedback or further suggestions. Aiming to merge and release tomorrow.

[AaronKutch]

It's perfect thank you.