time.time() across shards

[jeremy]

across shards of the platform, how close can i reasonably expect
time.time() to be synchronized? like, if request A precedes B, how
close would identical requests A and B have to be for me to worry
about B getting an earlier since-epoch value from the platform than A?

[Alexander Kojevnikov]

Check this thread:
http://groups.google.com/group/google-appengine/browse_thread/thread/92cb907b13585c3f/1e48dba24e998735

The clocks on different machines can be off by days, you shouldn't
rely on them being in sync.

--
www.muspy.com

[Jon McAlister]

Clock sync is generally within seconds between our appservers. The
other thread only has a second-hand account from a nameless source,
but I have found they generally are well synced. If you see any
instances of massive skew, let me know. That said, seconds may be a
lot of skew depending on what your app is doing. It's best to instead
rely on logical constructs (e.g. distributed counters, random ids)
than time.

On Oct 24, 12:30 pm, jeremy <jeremy.a...@gmail.com> wrote:
> off by DAYS?! what the hell google?!!
>
> that's completely unacceptable. how do i "structure around" that one?!
>
> On Oct 24, 2:41 am, Alexander Kojevnikov <alexan...@kojevnikov.com>
> wrote:
>
> > Check this thread:http://groups.google.com/group/google-appengine/browse_thread/thread/...

[jeremy]

i'm glad to hear that other thread was way off.

[Cesium]

Check out this thread for actual measurements:

http://groups.google.com/group/google-appengine/browse_thread/thread/802ae9f498be48d7/6dacddc47702cac3?lnk=gst&q=utc#6dacddc47702cac3

The data are encouraging, but I'd sure like to see a statement from an
authoritative source like:
"The appserver clock will deviate from UTC(NIST) by no more than X
seconds."

cesium

[ryan]

sorry, but we're unlikely to ever provide an upper bound on clock sync
across servers. jon's right that it will generally be in the
neighborhood of seconds, but providing a guarantee would be similar to
attempting global synchronization across a distributed system. you
should generally try to avoid depending on global counters at all, but
if you need one, you can use either datastore Key ordering or
datastore transactions, depending on your needs.

[Peter Recore]

I have a clarification question. Does this time skew also apply to
the datastore? In particular, if I have an entity with a
DatetimeProperty using the "auto_now" feature,
will the times in my property be potentially skewed? My guess is that
since the datastore is so distributed, the same kind of skew is
possible. This might be a good thing to mention in the docs for
DateTimeProperty, because so many of us are probably used to trusting
the database as a centralized place to get a timestamp.

-peter

[ryan]

good question! the timestamps for DatetimeProperties with auto_now and
auto_now_add are calculated and populated by the app servers, not by
the datastore. given that, the discussion here about clock
synchronization applies to them too.