One record says 09:00+02:00. Another says 07:00Z. If the date is the same and the notation is being used as specified, those can describe the same instant. Comparing only the clock digits creates a difference that the full timestamps do not contain.
Preserve the offset during import
In the RFC 3339 timestamp notation used here, an offset identifies the difference from UTC and Z denotes UTC. In this example, subtracting two hours from 09:00 gives 07:00 UTC. Keep the date as well, because converting near midnight can cross a calendar boundary.
Do not guess an offset for a record that contains only “09:00.” Ask what time convention the data provider used. A place name alone may also require date-specific timezone rules, so an improvised fixed adjustment can be wrong.
Make a comparison column
For a practice table, retain the original text and add a clearly labelled UTC comparison value. Put an explanation beside any conversion. This makes it possible to inspect the source without undoing your working column.
Use an invented pair that crosses midnight: 00:30+02:00 on 7 October corresponds to 22:30 UTC on 6 October. The arithmetic shows why keeping only a time-of-day column can lose the order of events.
Check the question before grouping by day
A local daily total and a UTC daily total may group the same events differently around midnight. Decide which day definition the analysis needs before counting, then state it in the output.
This extends our advice on writing a data dictionary. A timestamp column needs its time convention as well as its name. Once that information is preserved, a surprising order becomes something you can investigate rather than quietly fix by sorting the clock strings.