Timezones support is deficient

I think we should rethink how the timezones are applied, as we have more than one case of abbreviations with different meanings.

I could found at least these cases:

• ACT:

  • Acre Time: UTC−05
  • ASEAN Common Time (unofficial): UTC+06:30 – UTC+09

• AMT:

  • Amazon Time (Brazil): UTC−04
  • Armenia Time: UTC+04

• AST:

  • Arabia Standard Time: UTC+03
  • Atlantic Standard Time: UTC−04

• BST:

  • Bangladesh Standard Time: UTC+06
  • British Summer Time (British Standard Time from Feb 1968 to Oct 1971): UTC+01
  • Bougainville Standard Time: UTC+11
  • issues / PRs: https://github.com/scrapinghub/dateparser/pull/682

• CDT:

  • Central Daylight Time (North America): UTC−05
  • Cuba Daylight Time: UTC−04

• CST:

  • Central Standard Time (North America): UTC−06
  • Cuba Standard Time: UTC−05
  • China Standard Time: UTC+08

• ECT:

  • Ecuador Time: UTC−05
  • Eastern Caribbean Time: UTC−04

• GST:

  • Gulf Standard Time: UTC+04
  • South Georgia and the South Sandwich Islands Time: UTC−02

• IST:

  • Irish Standard Time: UTC+01
  • Israel Standard Time: UTC+02
  • Indian Standard Time: UTC+05:30
  • issues / PRs: https://github.com/scrapinghub/dateparser/issues/580 https://github.com/scrapinghub/dateparser/issues/609 https://github.com/scrapinghub/dateparser/issues/636 https://github.com/scrapinghub/dateparser/pull/637

I'm not sure about the solution we could implement, but it's obvious that we can not choose a timezone randomly.

Some ideas:

• We could choose the most used, for example, we could maybe change IST from "Israel Standard Time" (current) to "Indian Standard Time" (hard to decide, not a solution itself).
• We could add a warning when parsing timezones with more than one meaning (self-explanatory, but not a solution and it could be a problem when people already know it, as it could spam with a lot of warning messages).
• We could add a setting like "PREFER_TIMEZONE_FROM" or something similar where users can specify if they prefer timezones from a continent or another negative vs positive timezones (I'm not sure about this, as there are some examples in the list (like CDT or ECT) where all the timezones are from the same continent/region).
• We could add a setting that would allow specifying preferent manual timezones (example: TIMEZONES_EQUIVALENT = {'IST': '+5.30'}). (possible solution but a hard to discover behavior).
• We could implement some of the above ideas together.

On the other side, we should think about how we could implement more timezones formats like 'Australia/Sydney': https://github.com/scrapinghub/dateparser/issues/298

Please, if you have any idea add a comment here below 👇 Any idea will be welcomed!!!

The issue does not name specific files, tests, or entry points; start by locating the timezone-abbreviation handling and reviewing the related issues and pull requests linked in the report. Done would require an agreed disambiguation strategy, support for the requested timezone formats, and tests covering the listed conflicting abbreviations.