Implement `Default` for `DateTime<FixedOffset>`

[indiv0]

Would it be viable to implement the Default trait for DateTime<FixedOffset>?

Adding this in would be very useful for deserializing AWS responses in the rusoto project.

[lifthrasiir]

I don't think it is viable; DateTime has no special value (something like NaN in floats). I'm not sure why it would be useful for rusoto, can I ask you for the details?

[indiv0]

Rusoto has a codegen crate which is used to generate the structs necessary to deserialize responses from AWS. Those types have #[derive(Default)], which isn't valid unless all of the fields also derive Default. Some of those structs have fields which correspond to timestamp responses from AWS, which we'd like to deserialize to DateTime<FixedOffset> instead of String (which is what we do now). However, we can't do this as changing the type from String to DateTime<FixedOffset> results in the structs being unable to implement Default.

[lifthrasiir]

@indiv0 That exactly sounds like that you actually need Option<DateTime<FixedOffset>>. AFAIK It does not affect the (de)serialization format (unless the value itself may be serialized into null, but DateTime doesn't). You have already allowed an empty String (which is obviously invalid), so it shouldn't be a big deal I think?

[indiv0]

@lifthrasiir I've pulled you into the discussion in the PR: rusoto/rusoto#235. Per what I wrote at the end there (depending on what the rusoto maintainers say), I don't think Option<DateTime<FixedOffset>> will be viable, since there are cases where we expect a DateTime<FixedOffset> everytime, so it can't be optional in those cases.

Specifically for your empty String example, in any scenario where the resulting String can be empty, we wrap it in an Option<T> in the generated struct.

Keeping that in mind, wouldn't it be possible to just default to the equivalent of 0000-01-01T00:00:00-00:00?

[indiv0]

Per the comments made here, and the relevant issue that was opened here, rusoto has decided to instead move away from providing Default implementations for the auto-generated types. As such, I'm going to close this issue.

Thank you for your help and input!