Bugzilla

I agree with Simon in comment 13 and disagree with comment 2 and comment 10.

It gets worse if the time zone revealed is more than an offset; in terms of revealing nature:
Most revealing → Africa/[Bangui](https://en.wikipedia.org/wiki/Bangui "(Capital of the Central African Republic)") > [West Africa Time](https://en.wikipedia.org/wiki/West_Africa_Time) > Europe/London > [British Summer Time](https://en.wikipedia.org/wiki/British_Summer_Time) > +0100 → Least revealing

I'm not sure exactly what is visible (I assume it's just the offset), but even the offset is extremely telling in certain areas such as Nepal, Bangladesh, various islands in the Atlantic and Pacific, etc. It's even more telling combined with language preferences (which we'll never be able to control). Also consider all the summer time / daylight savings differences in adoption and timing.

I'd probably object less to some kind of popularity-driven TZ approximation, where your time zone is reported as the closest "sufficiently popular" time zone (which would need to be determined somehow), but that'd likely lead to a good amount of end-user confusion. (It'd also still be revealing when your TZ changes due to summer time / daylight savings unless the browser also rounds that to a less revealing time, which would contribute to even more confusion.)

I agree with Simon in comment 13 and disagree with comment 2 and comment 10.

It gets worse if the time zone revealed is more than an offset; in terms of revealing nature:
→ Africa/[Bangui](https://en.wikipedia.org/wiki/Bangui "(Capital of the Central African Republic)") > [West Africa Time](https://en.wikipedia.org/wiki/West_Africa_Time) > Europe/London > [British Summer Time](https://en.wikipedia.org/wiki/British_Summer_Time) > +0100 > +0000

I'm not sure exactly what is visible (I assume it's just the offset), but even the offset is extremely telling in certain areas such as Nepal, Bangladesh, various islands in the Atlantic and Pacific, etc. It's even more telling combined with language preferences (which we'll never be able to control). Also consider all the summer time / daylight savings differences in adoption and timing.

I'd probably object less to some kind of popularity-driven TZ approximation, where your time zone is reported as the closest "sufficiently popular" time zone (which would need to be determined somehow), but that'd likely lead to a good amount of end-user confusion. (It'd also still be revealing when your TZ changes due to summer time / daylight savings unless the browser also rounds that to a less revealing time, which would contribute to even more confusion.)