If we want to implement the feature flag, we need to figure out how to map
the old timezone names to the IANA names.

The timezone mappings that are in use in 3.0 are not always sensible and
sometimes they are downright misleading. This stems from the issues
surrounding the current implementation of the timezone lookup function
(TimezoneDatabase::FindTimezone()). These issues are described in detail in

For instance, the lookup function currently interprets "CEST" as an alias
for "Africa/Ceuta". Since "CEST" stands for "Central European Summer Time",
I imagine users would expect to get "CET" ("Central Europian Time")
timezone or the timezone of some Central European city instead (e.g.
Europe/Paris or Europe/Budapest). Note, that although all these timezones
use the same DST offset they are different timezones with different rules.

So which mapping should we use when the feature flag is set?  I don't think
there is a good answer here. Whichever mapping we choose, chances are users
won't be happy with it and we would have to change it later.

In summary. instead of trying to hard-code the 3.0 mappings (including the
ambiguous/misleading ones) under a feature flag, I think it would make more
sense to provide users with a config file that contains most legacy
timezone names with some sensible mappings. Users can start with that and
then remove/add/modify timezone mappings as they see fit. I think this way
we could avoid a lot of confusion
On Wed, Jun 13, 2018 at 8:03 PM, Jim Apple <[EMAIL PROTECTED]lid>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB