> If your application is future-dating items, like say clients entering appointments in a calendar, this will be very wrong.
Well, the future has problems no matter what you do.
> If a customer enters an appointment 6 months in the future, it will end up at the wrong time due to daylight savings time.
No, becauae that you store UTC doesn't mean that you also convert entries to UTC using the offset on the entry date without looking at the date the time is attached to.
OTOH, no matter what you store, the fact that DST rules and even timezone boundaries can change over time means that you have to store a lot more about the intent than just the time to be certain of being correct for future times. Did you want X time in Y time zone or X time in the legal time applicable to Z venue? The former is often used as a proxy forthe latter on the assumption that tim zones don't change...
Well, the future has problems no matter what you do.
> If a customer enters an appointment 6 months in the future, it will end up at the wrong time due to daylight savings time.
No, becauae that you store UTC doesn't mean that you also convert entries to UTC using the offset on the entry date without looking at the date the time is attached to.
OTOH, no matter what you store, the fact that DST rules and even timezone boundaries can change over time means that you have to store a lot more about the intent than just the time to be certain of being correct for future times. Did you want X time in Y time zone or X time in the legal time applicable to Z venue? The former is often used as a proxy forthe latter on the assumption that tim zones don't change...