RFC: drop datetime feature (or drop FieldValue)

[lnicola]

I think we should drop the feature and eat the extra dependency.

chrono builds in about 3 seconds and having different code paths can be annoying (see 3765736 for a recent example, where clippy failed because of an apparently infallible function returning Result).

[lnicola]

One more argument for this: feature-gating an enum value can make dependent crates stop building if the feature gets pulled in by another crate. I gave an example in georust/wkt#50 (comment).

[lnicola]

On the other hand, we could try to do this "the right way" and define a set of conversion traits. This way we could get rid of the enum and still be able to make the chrono dependency optional.

One problem with this approach would be the "loose" typing we currently have in FieldValue::into_foo.

[ChristianBeilschmidt]

For me, time is essential to geoprocessing, so I don't see the point in having this feature-gated.

And if we keep it, I guess you are right in working on the enum value.

[jdroenner]

we can drop the feature gate now and change to conversion traits later. I think the additional dependency is fine.

[lnicola]

Actually, chrono is currently unmaintained, we should also look into using the time crate instead.

In a different PR, of course.

[jdroenner]

really? That is very unfortunate.

[lnicola]

Yeah, see e.g. this soundness issue from one year ago: chronotope/chrono#499. https://github.com/chronotope/chrono/commits/main shows some movement, but the last commit before was from January.

[jdroenner]

if i get it right the issue is with localtime and time removed that in 0.3. I guess we will never need local time and should be able to use time instead.