I am currently designing a web/mobile application the bulk of whose users will be distributed across the different U.S. time zones with a potential of scaling up to other countries and time zones as wellI have worked with several other globally used apps and noticed they all used datetime to record timestamps with the default time zone being that in which the application is typically hosted.  In displaying the times, they would typically do not care about the user preference (locale) and simply display the timestamp with the TZ and leave it up to the user to convert if (s)he wishes.I am entertaining the idea of shifting away from that paradigm and recording timestamps as one global time (GMT) in long milis regardless of the user location and collecting the user locale by their IP or letting them change their TZ as a preference in their profile, which would later be used for display formatting of all their GMT long milis.  This seems like a simpler solution than confusing the app design with TZs.I am curious to hear feedback of pros and cons to this approach.  I am also curious to hear some explanations why the, IMO overcomplicated time zoned datetime data type has ever been used across databases and not a uniform single time zone with conversions just for display. 
(Dis)advantages of datetime vs. long in globally used applications
database design;time
I don't think you're going to gain much by storing all of your datetimes as longs.  Every language I can think of has ways to convert dates to other formats (string, long) use the preferred format for your database.Store the dates in UTC.  I think this makes sense for nearly every application, since many languages and APIs have a way to get Now() in UTC.  Also, for most devices and browsers it's trivial to figure out the timezone offset.  Then it's simple addition for displaying a user's local time.  You will save yourself much headache down the road.