The DetectionTime value is taken from the log, and effectively a timestamp with timezone is assigned to stamp an absolute time at the time the log is read (say, at the agent, syslog server, or if you're forwarding syslog all the way to the LEM appliance, to the LEM appliance).
Generally, though, we don't take the timestamp from within the device log, we take it from the syslog protocol's timestamp. That way we can avoid some of the timezone/stamp gaps and assign a complete timestamp. If you're syslogging directly to the appliance, a timestamp is logged with syslog that's an absolute unix timestamp, and we take that literally.
Once it's received at one of those trusted points - the agent or appliance - an InsertionTime is also assigned, which has a timezone factored in also. Both of these absolute times are stored in the database and with the event as it's presented to your console.
Rules will use DetectionTime to process whether something is in scope, so it's possible if somehow the timezones are too far out of whack that the agent/appliance can't/don't adjust, you might see some rules that don't fire. Best solution would be to have a syslog server/agent receive data in those timezones so it gets stamped as expected with the right absolute timestamp for that timezone.
Your Console will adjust for your viewing timezone based on the adjustment between the absolute timestamp and your timezone. So, you'll see events as they occur with Detection/InsertionTimes that make sense for you.
There's actually a third timestamp that gets assigned, which is the time that an event was received at the appliance. This isn't really visually presented, but ensures that when you run reports, your reports don't have gaps.
Effectively, LEM should handle time so you don't have to worry about it.