Paul Dicker

> My end goal is to support #281 and to improve localization overall - although I suppose it is subjective if the data from icu is better than the data...

> So a 3M binary size penalty seems like a big downside... We already don't include timezone data but leave it in chrono-tz because it would add 2+ Mb to...

Some links for a bit of context/history of our localization support: - https://github.com/chronotope/chrono/pull/453 - https://github.com/chronotope/chrono/issues/475 - https://github.com/chronotope/chrono/pull/1152 - https://github.com/chronotope/chrono/pull/1165 Some of the goals where to not generate the data at...

> So a 3M binary size penalty seems like a big downside... > I don't think our strftime-format string is going to be flexible enough to provide optimal localized formatting....

Yes, I was somewhat surprised by this also, see https://github.com/chronotope/chrono/pull/1088#pullrequestreview-1448084460. In many cases it makes sense that `DateTime`'s can be compared/ordered independent of the timezone, but in some cases you...

> Are there cases in which it makes sense for two datetimes that have the same hour, but in different timezones to be considered equal? I'm struggling to imagine an...

@lovasoa Do you already have a workaround? What would be the comparison you need? Should besides the timestamp the offset be equal, the type, of both?

@msdrigg Maybe you want to double-check? Because chrono does compare the actual instant, all values are converted to UTC internally.

@simon04 Thank you for working on this. Sorry I never updated https://github.com/chronotope/chrono/issues/945, but I hope to fix offset parsing in a more complete way with https://github.com/chronotope/chrono/pull/1082, https://github.com/chronotope/chrono/pull/1083, and a part...

Closing for the reason mentioned above. Thank you @simon04 for your work here!