Of course. I'm not about to re-architect my current applications as the effort is not justified. But if I had the luxury of approaching timestamps fresh I would take this approach to it.
-- rk -----Original Message----- From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Paul McNett Sent: Thursday, June 12, 2014 10:17 PM To: profoxt...@leafe.com Subject: Re: UTC and why you should use it On 6/12/14, 11:17 AM, Richard Kaye wrote: > Rick's assertion is that you always store UTC values and then convert in the > UI as needed. If it's important to know the TZ where the transaction took > place then you should store that as another data element. You gotta be flexible though. If the company has always stored its dates in Pacific Standard Time, it may not make sense to switch to storing in UTC, given all the legacy apps and databases that could be in use and would need to be updated. By changing the policy, you've doubled the headache. As long as you have a company-wide standard, UTC or whatever can be easily derived from that. Paul _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/DF1EEF11E586A64FB54A97F22A8BD044239C076B93@ACKBWDDQH1.artfact.local ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
