For a given calendar date/time, it is not possible as a general rule to predict what actual time (seconds since the epoch) that represents. Time zones change and DST rules change. It's a fact of life. DST has a tortured history in Australia. DST rules have been very unpredictable in Israel. DST rules recently changed in the US causing huge headaches for Microsoft who was storing seconds rather than calendar dates.
Never save NSDate
when you mean NSDateComponents
. If you mean "the first of May 2013 in London," then save "the first of May 2013 in London" in your database. Then calculate an NSDate
off of that as close to the actual event as possible. Do all your calendar math using NSDateComponents
if you care about calendar things (like months). Only do NSDate
math if you really only care about seconds.
EDIT: For lots of very useful background, see the Date and Time Programming Guide.
And one more side note about calendar components: when I say "the first of May 2013 in London," that does not mean "midnight on the first of May." Don't go adding calendar components you don't actually mean.