Consider making TimeZone: Send + Sync

[rnarubin]

The TimeZone trait is not bound to Send or Sync, although most (all?) implementations would meet the requirements. This makes it difficult to work with generic DateTime<Tz> in multithreaded environments.

My particular use case is that I have an error enum for a date which might be out of certain bounds. In using the failure crate my errors must be Send + Sync, so this can't be generic over a DateTime<TimeZone> because the TimeZone trait doesn't meet the bounds. I'd either have to convert to a concrete timezone like Utc or use naive time.

#[derive(Debug, failure::Fail)]
pub enum DateOutOfBounds {
    #[fail(display = "Date is too early: {}", _0)]
    TooEarly(chrono::NaiveDateTime),
    #[fail(display = "Date is too late: {}", _0)]
    TooLate(chrono::NaiveDateTime),
}

[quodlibetor]

With some fairly verbose trait bounds it is possible for you to do this right now:

#[derive(Debug, failure::Fail)]
pub enum DateOutOfBounds<Tz>
where
    Tz: chrono::TimeZone + Send + Sync + std::fmt::Display + std::fmt::Debug + 'static,
    Tz::Offset: Send + Sync + std::fmt::Display + std::fmt::Debug + 'static,
{
    #[fail(display = "Date is too early: {}", _0)]
    TooEarly(chrono::DateTime<Tz>),
    #[fail(display = "Date is too late: {}", _0)]
    TooLate(chrono::DateTime<Tz>),
}

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=7d3aa3ea16241300e5dc91fa67b3627c

Send and sync does seem pretty reasonable to require of Tzs, the only use case I can think of that would be unsync would be some object that goes out and hits the system timezone db or something, but that is such a heavy operation that just sticking the tz behind an Arc might be fine?

Adding these constraints is a backwards-incompatible change, so we've got some time to think about it. If anyone has thoughts about unsync things they would like to be able to do with timezones I would love comments.