> the key fact is not request.now, or request.utcnow but the fact that you can define your table to update these fields automatically so you can forget about them
Thank you for your thoughtful answer, but that wasn't what I was asking (apologize for the misunderstanding), and if you actually rely on the timestamp in computations, rather than just display it, then the difference between request.now and request.utcnow is the difference between a working-as-advertised system and a once-or-twice-a-year cannot-reproduce kind of bug. See, if a record was created on 2:58am on the day of the daylight-saving change, and then I check for all updates >= 2:58am, I get it. Then, time moves back to 2:00am instead of 3:00am; a new record gets created on 2:02am (4 minutes _after_ the previous update). Then to see what's new since the last update, I check updates >=2:58am again -- and the new one will not be reported That's what I'm trying to solve, not the fact that they will automatically be inserted.
