We're doing synchronization between more than one system (not just
google) and so the same contact may have been updated at timeA (as
reported by systemA), at timeB (as reported by systemB), ... I don't
want to compare timeA to timeB directly when deciding which update has
happened later so I am trying to figure out the approximate server
time difference to use as an error threshold. Under the threshold I
can't really say which server updated later, but over the threshold I
can. So I want to be able to tell the current time differences between
our server and serverA, our server and serverB, our server and serverC
and so on ...

 When saving the update time reported by serverA,B,C,... in our local
db I'd like to adjust the reported time by the servers time difference
to always save it in accordance to our server's time.

 Let me know if this makes sense to you.

On Thu, Sep 8, 2011 at 9:50 AM, Alain Vongsouvanh <[email protected]> wrote:
> Hello Alexey,
> I am sorry but I assumed you were updating the same contact twice as it
> shows up in the log you provided:
> 2011/08/08 19:35:01:282 PDT [WARN] ImapConnection - GMail ~ updated1:
> 2011-08-09T02:29:25.787Z, value: 1312856965787, etag:
> "RHkzfzVSLit7I2A9WhdRGEgMTgI."
> 2011/08/08 19:35:01:553 PDT [WARN] ImapConnection - GMail ~ updated2:
> 2011-08-09T02:33:10.382Z, value: 1312857190382, etag:
> "QX0zejVSLit7I2A9WhdRGEgNRg0."
>    Time diff (min): 1
> 2011/08/08 19:35:11:198 PDT [WARN] ImapConnection - GMail ~ updated1:
> 2011-08-09T02:29:25.787Z, value: 1312856965787, etag:
> "RHkzfzVSLit7I2A9WhdRGEgMTgI."
> 2011/08/08 19:35:11:499 PDT [WARN] ImapConnection - GMail ~ updated2:
> 2011-08-09T02:29:25.787Z, value: 1312856965787, etag:
> "RHkzfzVSLit7I2A9WhdRGEgMTgI."
>    Time diff (min): 5
> Can you explain why you would need the time difference between Google's
> servers and your environment? If this is for subsequent GET requests using
> the "updated-min" query parameter, I would advise you to use the latest
> <updated> element in the result feed instead of storing the time in your
> environment.
> Doing that will ensure that you are using Google's data and not your
> environment's which can be out of sync and will also prevent race condition
> (somebody updated a contact between your query and the line that stores the
> current time).
> Best,
> Alain
>
> On Wed, Sep 7, 2011 at 11:10 AM, Alexey Panteleev <[email protected]> wrote:
>>
>> No, I am not updating it twice, only once. I print the etag before the
>> update and after (so you see those two lines).
>> But what I see is that for other contacts the update is happening even
>> though I am updating a record that has not changed.
>>
>> What I am trying to do is to figure out the approximate time difference
>> between our and google servers.
>> Is there a better way to find out the current server time?
>>
>>
>> On 9/7/11 8:38 AM, "Alain Vongsouvanh" <[email protected]> wrote:
>>
>> Hello Alexey,
>>
>> Unfortunately, the Contacts API won't generate a new Etag or new updated
>> date if nothing has been updated. However, I am still wondering why your
>> application isn't getting any 412 exceptions as you are trying to modify the
>> same contact twice with the same etag:
>>   1. First update works as you get a new Etag and new updated date.
>>   2. Second update should fail with a 412 Precondition Failed exception
>> since you are trying to update a contact with an old Etag.
>>
>> Best,
>> Alain
>>
>> On Tue, Sep 6, 2011 at 5:58 PM, Alexey Panteleev <[email protected]> wrote:
>>
>> The problem here seems that
>>
>> entry = myService.update(new URL(entry.getEditLink().getHref()), entry);
>>
>> simply does not do anything for some records. Is there any way to force
>> the update?
>>
>> before update: 2011-09-07T00:34:47.503Z, value: 1315355687503, etag:
>> "Rns7ezVSLyt7I2A9WhdWE0gPQQw."
>> after update: 2011-09-07T00:34:47.503Z, value: 1315355687503, etag:
>> "Rns7ezVSLyt7I2A9WhdWE0gPQQw."
>>
>> On 8/9/11 9:22 AM, "Alain Vongsouvanh" <[email protected]
>> <http://[email protected]> > wrote:
>>
>> Hello Alexey,
>>
>> Please see my comment inline:
>>
>> On Mon, Aug 8, 2011 at 7:38 PM, Alexey Panteleev <[email protected]
>> <http://[email protected]> > wrote:
>>
>> Our app reads from the feed upon user’s request and as a test executes
>> this:
>>
>> entry = myService.update(new URL(entry.getEditLink().getHref()), entry);
>>
>> It seems this update command does not always update the record and so I
>> compute the time diff based on some old update time.
>>
>> 2011/08/08 19:34:42:814 PDT [WARN] ImapConnection - GMail ~ updated1:
>> 2011-08-09T02:29:27.253Z, value: 1312856967253, etag:
>> "Rnw-ezVSLit7I2A9WhdRGEgMTgI."
>> 2011/08/08 19:34:43:117 PDT [WARN] ImapConnection - GMail ~ updated2:
>> 2011-08-09T02:32:51.932Z, value: 1312857171932, etag:
>> "QHc4ejVSLit7I2A9WhdRGEgNRgM."
>>    Time diff (min): 1
>> 2011/08/08 19:35:01:282 PDT [WARN] ImapConnection - GMail ~ updated1:
>> 2011-08-09T02:29:25.787Z, value: 1312856965787, etag:
>> "RHkzfzVSLit7I2A9WhdRGEgMTgI."
>> 2011/08/08 19:35:01:553 PDT [WARN] ImapConnection - GMail ~ updated2:
>> 2011-08-09T02:33:10.382Z, value: 1312857190382, etag:
>> "QX0zejVSLit7I2A9WhdRGEgNRg0."
>>    Time diff (min): 1
>> 2011/08/08 19:35:11:198 PDT [WARN] ImapConnection - GMail ~ updated1:
>> 2011-08-09T02:29:25.787Z, value: 1312856965787, etag:
>> "RHkzfzVSLit7I2A9WhdRGEgMTgI."
>> 2011/08/08 19:35:11:499 PDT [WARN] ImapConnection - GMail ~ updated2:
>> 2011-08-09T02:29:25.787Z, value: 1312856965787, etag:
>> "RHkzfzVSLit7I2A9WhdRGEgMTgI."
>>    Time diff (min): 5
>>
>>
>> The last 6 lines seem to indicate that you tried to update the same entry
>> (in bold) twice (with etag "RHkzfzVSLit7I2A9WhdRGEgMTgI"), the second update
>> should have failed and the API should have thrown a 412 Precondition Failed
>> error since the etag was outdated.
>> This can happen if a user tries to update a contact twice in a row and
>> your app didn't have the time to save the contact returned by the API in
>> your local storage.
>>
>> To avoid this kind of race condition, your application should always try
>> to retrieve the contact from the API before every update.
>>
>> Best,
>> Alain
>>
>>
>> On 8/8/11 11:31 AM, "Alain Vongsouvanh" <[email protected]
>> <http://[email protected]>  <http://[email protected]> > wrote:
>>
>> Hello Alexey,
>>
>> Are you using batch requests to update your contact? Can you make sure
>> that the contact has indeed been updated?
>> It might be hard to test but one thing you could try is printing the value
>> of updated before and after the update to make sure that it changes.
>> Another thing is to make sure that the contact's etag changed as well.
>>
>> Best,
>> Alain
>>
>> On Sun, Aug 7, 2011 at 1:26 PM, Alexey Panteleev <[email protected]
>> <http://[email protected]>  <http://[email protected]> > wrote:
>>
>> Hi Alain,
>>
>>  I read recently updated contacts from the feed and execute the update for
>> each to measure the timestamp difference.
>> What I see is that for some contacts the difference is abnormal (I printed
>> out the entry.getUpdated() this time also):
>>
>> 2011/08/07 13:20:30:956 PDT [WARN] GMail ~ Time diff (min): 1, str:
>> 2011-08-07T20:18:15.362Z
>> 2011/08/07 13:20:39:099 PDT [WARN] GMail ~ Time diff (min): 1, str:
>> 2011-08-07T20:18:43.648Z
>> 2011/08/07 13:20:49:630 PDT [WARN] GMail ~ Time diff (min): 62, str:
>> 2011-08-07T19:17:54.834Z <---- 62min?
>> ...
>>
>>
>>  I am using the following versions in my maven setup:
>>
>> <properties>
>>        <gdataVersion>1.41.5</gdataVersion>
>>    </properties>
>>
>> <dependency>
>>                <groupId>com.google.gdata</groupId>
>>                <artifactId>gdata-contacts-3.0</artifactId>
>>                <version>${gdataVersion}</version>
>>            </dependency>
>>            ...
>>            <dependency>
>>                <groupId>com.google.gdata</groupId>
>>                <artifactId>gdata-client-1.0</artifactId>
>>                <version>${gdataVersion}</version>
>>            </dependency>
>>            <dependency>
>>                <groupId>com.google.gdata</groupId>
>>                <artifactId>gdata-core-1.0</artifactId>
>>                <version>${gdataVersion}</version>
>>            </dependency>
>>            <dependency>
>>                <groupId>com.google.collections</groupId>
>>                <artifactId>google-collections</artifactId>
>>                <version>1.0</version>
>>            </dependency>
>>
>>
>> On 8/5/11 9:47 AM, "Alain Vongsouvanh" <[email protected]
>> <http://[email protected]>  <http://[email protected]>
>>  <http://[email protected]> > wrote:
>>
>> Hello Alexey,
>>
>> Sorry about the delay in getting back to you! I just tried updating and
>> checking the difference between my computer timestamp and the updated value
>> timestamp and the difference was within 1 or 2 seconds, not hours.
>>
>> Can you try printing the value of "entry.getUpdated()
>> " to check if the string representation makes sense. Also, what version of
>> the client library are you using?
>>
>> Best,
>> Alain
>>
>>
>> On Tue, Aug 2, 2011 at 1:02 PM, Alexey Panteleev <[email protected]
>> <http://[email protected]>  <http://[email protected]>
>>  <http://[email protected]> > wrote:
>>
>> Hello,
>>
>>
>>
>>  I've been running some experiments monitoring the Updated timestamp on
>> contact records:
>>
>>
>>
>> long t1 = System.currentTimeMillis();
>>
>> entry = myService.update(new URL(entry.getEditLink().getHref()), entry);
>>
>> long updateTimeDiff = t1 - entry.getUpdated().getValue();
>>
>>
>>
>>  What I see is that the time difference between the update time and my
>> local time varies drastically from one call to another,
>>
>> one time I see 1min difference another time it is 50min difference, which
>> really means that the google servers record very different utc timestamps
>> for events that actually happen next to each other.
>>
>>
>>
>>  Can you please explain this and also tell me how I could rely on these
>> timestamps during synch
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Google Contacts, Shared Contacts and User Profiles APIs" group.
>> To post to this group, send email to
>> [email protected]
>> To unsubscribe from this group, send email to
>> [email protected]
>> For more options, visit this group at
>> http://code.google.com/apis/contacts/community/forum.html
>
>
>
> --
> Alain Vongsouvanh
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Google Contacts, Shared Contacts and User Profiles APIs" group.
> To post to this group, send email to
> [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://code.google.com/apis/contacts/community/forum.html
>



-- 
Founder / Project Lead
Yoxel Systems

Skype ID: yoxel.com
Twitter: @yoxeldotcom
Telephone: +1 415 230 0189

-- 
You received this message because you are subscribed to the Google
Groups "Google Contacts, Shared Contacts and User Profiles APIs" group.
To post to this group, send email to
[email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://code.google.com/apis/contacts/community/forum.html

Reply via email to