First, note that TimeZone != Offset. See the timezone tag wiki.
Second, if you are aggregating by the target date in multiple time zones, you may want to just pick a handful of relevant time zones and precompute their local dates into unique columns in your data. Then it will be easy to aggregate at time of query. Of course, this strategy doesn't hold up if you want to support all 500+ time zones in the IANA tzdb.
Another strategy would be to round to build another set of tables that pre-aggregates items into 15 minute buckets. Why 15 minutes? Because not all time zone offsets are in terms of whole hours. Consider -4:30 used in Venezuela, +5:30 used by India, +5:45 used in Nepal, and +8:45 used in parts of Australia. Once you have these pre-aggregates, you can transform those to the details of the specific client timezone at time of query.
And finally, you might consider that a relational database like MySQL may just not be the best tool for this particular job. An OLAP cube would work quite well, and so might a map/reduce function in any of several nosql databases. You may want to replicate your data from MySQL to a separate "reporting store" or "data warehouse", and query from there.