Fortunately for you I have a cold and I'm not quite up to a purely cliche based response. But time will tell.
I think the Names field is instructive here as a way to cope with time and date issues.
Best practice is to store canonical or at least abbreviated and then display common. The data is the data but the representation of the data needs to be human friendly.
So, store date-time info always with time zone info - the "fully qualified time" if you will. Logic then needs to take this into account when evaluating and displays are free to present a human friendly time.
Not so much thinking out of the box as taking a page from tried and true methods, but at the end of the day... it's horses for courses.
Fortunately for you I have a cold and I'm not quite up to a purely cliche based response. But time will tell.
I think the Names field is instructive here as a way to cope with time and date issues.
Best practice is to store canonical or at least abbreviated and then display common. The data is the data but the representation of the data needs to be human friendly.
So, store date-time info always with time zone info - the "fully qualified time" if you will. Logic then needs to take this into account when evaluating and displays are free to present a human friendly time.
Not so much thinking out of the box as taking a page from tried and true methods, but at the end of the day... it's horses for courses.