On Fri, Mar 8, 2013 at 3:04 PM, Karen Etheridge <p...@froods.org> wrote:
> > my $0.02: **always** store timestamps in ISO8601 format (UTC), or in unix > epoch (integer) format **only**. Local timezones should only get applied > when rendering data for user consumption - i.e. as late as possible, and > after all calculations have been performed. When processing timestamps > input by a user, convert to UTC as soon as possible, before storage and > before applying any math. > I know what you are saying and it's good advice. UTC is a timezone, too. If you want to represent a point in time so that you can later render it in a user's timezone or compare it to another time you must include the time zone. In our database we use "timestamp with time zone" and it doesn't matter what timezone the database session uses as long as we use the timezone when parsing the column data. If you have two DateTime objects (where is_floating is false) then AFAIK they can be compared regardless of time zone of each DateTime, object. That is, they both represent a point in time. When rendering we convert to the user's timezone (as they have chosen in their preferences). And as Zefram noted, "durations are not arithmetically well behaved", and so it using UTC is useful when working with durations for the DST issues I originally posted about. > There's a good (and lengthy) discussion at > https://metacpan.org/module/DateTime#How-DateTime-Math-Works, which ends > with very similar advice. > Good read, yes. -- Bill Moseley mose...@hank.org
