Paul Dicker

Did you re-open for a reason?

The CI should be green or less red if we use the new feature names. `size_16` is renamed to `pointer_width_16`, and the same for `size_32` and `size_64`.

See https://github.com/chronotope/chrono-rfcs/pull/2 which continues this issue.

#1457 should be able to fix this.

I think parsing time zone abbreviations is something we should support at some point. That some are ambiguous does not mean we can't parse any. Chrono would need a deeper...

Interesting! I have no idea yet... Some more example code: ```rust use chrono::{FixedOffset, Offset, TimeZone}; use chrono_tz::America::Chicago; fn main() { let date1 = Chicago.timestamp_opt(236246216400, 0).single().unwrap(); println!("{:?} {}", date1, date1.offset().fix()); let...

So the problem here is that chrono-tz only includes data for a fixed set of years, with the end of this century as the limit. We should at least document...

We have to keep at least one issue open :smile:. I think it can be this one for now.

Note that this PR pioneers a new technique for OSM-carto: masking. I see no real problems caused by it, but had to learn two tricks: - setting a gamma value...

One more comparison: with `comp-op: darken` the pixels along a boundary where not aliased consistently, while they are with masking. With `comp-op: darken`:  With masking: