I've been fortunate enough to gain a fair bit of experience with Office 365, not just through my own blog, but during my 9 to 5 as well. Needless to say, working with SharePoint Online is worlds away from the familiarity of an on-premise environment.
Vigilant developers will always check timezones when they are working with dates, however for the developers that are...much like myself, this isn't usually the case. So when you're working with SharePoint Online, if you obtain a date value from a SharePoint list item (for example), then the timezone for that value will correspond to the regional settings for the site that the data resides in. No big deal there.
However, if you are obtaining data from different sites with different timezones, or (more commonly) working with a system time such as System.DateTime.Now(), then there's no guarantee that you're looking at dates within the same timezone. BOOM! The code you're used to seeing working flawlessly has died as soon as its provisioned online.
The first lesson is to avoid calling DateTime.Now when working with Office 365. Here a few helper methods that ensure a DateTime object is using the timezone of the SPWeb you are using.
public static DateTime Now(this SPWeb web)
public static DateTime
LocalTime(this SPWeb web, DateTime dateTime)
Update (26th August 2013) :
Make sure that you don't use this LocalTime method for DateTime values obtained from SharePoint data. In my findings, the Kind property for SharePoint dates is "Unspcified". When calling dateTime.ToUniversalTime(), the DateTime value will be treaded as having the same time zone as a system date.