Non-additive features yield BollardDate incompatibility

[jwest23]

I am using bollard twice; once directly, and once indirectly.

Indirectly, I am using bollard via the dockertest crate. It depends on bollard 0.17.1 with the default feature set. Without any further interference, bollard-stubs ends up with the BollardDate type alias for String. The dockertest crate understandably works with bollard as if BollardDate is a String.

Directly, I am using bollard to run containers for other purposes and have enabled the buildkit feature. This enables the chrono feature. With chrono enabled, bollard-stubs ends up with the BollardDate type alias for chrono::DateTime<chrono::Utc>> which seems right. That substitution is done here.

The result of this is that I cannot have both dockertest and bollard with buildkit enabled in the same crate. When I try to compile, I end up with errors where the dockertest crate is trying, for example, to call .as_str() on a timestamp from bollard_stubs::models::Network.created. The dockertest crate is expecting that to be an Option<String> and this would compile fine until the chrono feature is introduced. When chrono is enabled, the type changes to Option<chrono::DateTime<chrono::Utc>> and chrono::DateTime<chrono::Utc>> does not support the .as_str() method.

Is there any way to resolve this quickly that I've missed? I could try to get rid of my dependence on the buildkit feature. Failing that, the only solutions I see are to replace every BollardDate instance with String or to make BollardDate a type instead of a type alias so that it can have a well-defined interface that does not change based on the enabled features. The latter two are no small amount of work, but I'm hoping to avoid the former. If there's another path through, I'd appreciate you pointing me in the right direction.

Thank you for the fantastic crate and for giving this your attention!