Please kindly explain what is the impact of the system like shopping cart in which one customer(buyer) sits in one timezone and the other(seller) is on other timezone and the date is changed at one end. so the report data for one customer who bought is different than the other.
views:
136answers:
5
+2
A:
UTC forever! Seriously, it means you don't have to mess with daylight savings (or locality) adjustments in your model, only in the view.
Chris Jester-Young
2010-01-20 08:06:41
A:
The biggest "Pro" of using UTC is that if you choose to go with it then you can always be sure dates are stored that way and never have to doubt yourself. This saves a lot of hassle.
Robin Day
2010-01-20 08:08:32
+4
A:
If it represents a point in time, you should definitely use UTC. That sounds like the right choice in this particular case.
In some other cases, you want to store the local time - for instance, to represent an alarm which should go off at 8am in the local time, whatever time zone the user is in. This is usually useful for calendaring applications... and you're not storing a single point in time here.
One concrete example of why it's worth storing points in time in UTC is that local times can be ambiguous due to daylight saving transitions - if the clock goes back from 2am to 1am, there'll be a local time of 1:30am twice. In UTC, there's no such ambiguity.
Jon Skeet
2010-01-20 08:10:12
A:
i think,stored is not biggest problem,the most important is when set to some client like WEBSITE,API ...etc,you must send as UTC+0 format,maybe long type is better?
cjjer
2010-01-20 09:35:07
A:
UTC. I know a user in another forum that was storing local time from the end-user PC and some of the users decided that they didn't need auto adjust for DST. They are very sad now.
dbasnett
2010-01-20 13:23:17