db.define_table('your_table',
#your other fields here
Field(added_on, 'datetime', default=request.now),
Field(updated_on, 'datetime', default=request.now,
update=request.now),
)
and don't bother, just do inserts and updates
Using request.now is _guaranteeed_ to go backwards once a year in most of
the world (when going back from daylight saving time to standard time; the
date this happens differs between countries).
request.utcnow, which I mentioned in my original post (and appears in the
readme, but for some
Are you not able to code around the rare instance that the time goes
backward?
you are a strange man,
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
db.define_table('your_table',
Field('field1'),
Field('field2'),
Field(added_on, 'datetime',
I hate these kind of hacks.
In this case, a good solution (because of bandwidth and everything) would
be: give me all the updates since 1 hour _before_ what I think is the most
up-to-date update), and that would cover clocks going backwards up to 1
hour. And the cost would be in bandwidth,
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
Isn't there a time that doesn't change with daylight savings? Like time.time
or time.gmtime?
time.time or datetime.datetime.utcnow() both give you a number that is
independent of timezone (and datetime.utcnow() is supposed to be available
as request.utcnow, although that still isn't the case).
However, as I pointed out, there is still a chance that this can go
backwards in time on a
8 matches
Mail list logo
