CVS checkout problems with -D option

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

CVS checkout problems with -D option

CletusTSJY
I've just recently started trying out Hudson to see if it would be a good solution for my office but I'm having a hard time with the checkout command from CVS.  I notice that it uses the -D option and that doesn't appear to be configurable.  I assume the functionality is supposed to be that it uses the current time as an argument.  However, it's grabbing a time that is about 13 hours behind.  The result is that any changes in the last 13 hours don't take affect.  I've checked my server time and it is correct.  Is there anything I can do to correct this problem?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CVS checkout problems with -D option

Jesse Glick
CletusTSJY wrote:
> [cvs up -D is] grabbing a time that is about 13 hours behind.  The
> result is that any changes in the last 13 hours don't take affect.
> I've checked my server time and it is correct.

Perhaps your server admin confused localtime with UTC?

-J.

--
[hidden email]  netbeans.org  ant.apache.org  hudson.dev.java.net
             http://google.com/search?q=e%5E%28pi*i%29%2B1

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CVS checkout problems with -D option

CletusTSJY
Well, perhaps I'm confused.  The "date" command on the server returns 11:00 AM PDT (which is correct).  The date in the checkout command from hudson says "5:30 UTC".  The current time in UTC (according to http://tycho.usno.navy.mil/cgi-bin/timer.pl, which I have tested to be correct) is 18:00 UTC.  So it seems like Hudson's value is incorrect, unless that is not supposed to be the current time and I am misunderstanding the tool.

Thanks,
Cameron

Jesse Glick wrote
CletusTSJY wrote:
> [cvs up -D is] grabbing a time that is about 13 hours behind.  The
> result is that any changes in the last 13 hours don't take affect.
> I've checked my server time and it is correct.

Perhaps your server admin confused localtime with UTC?

-J.

--
jesse.glick@sun.com  netbeans.org  ant.apache.org  hudson.dev.java.net
             http://google.com/search?q=e%5E%28pi*i%29%2B1

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@hudson.dev.java.net
For additional commands, e-mail: users-help@hudson.dev.java.net
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CVS checkout problems with -D option

Jesse Glick
CletusTSJY wrote:
> The "date" command on the server returns 11:00 AM PDT (which is
> correct).  The date in the checkout command from hudson says "5:30
> UTC".

Don't know, works for me. You can try to debug it yourself and track
down the problem. Hudson should be specifying the UTC date corresponding
to the time the build in question started. See
hudson.scm.CVSSCM.configureDate.

-J.

--
[hidden email]  netbeans.org  ant.apache.org  hudson.dev.java.net
             http://google.com/search?q=e%5E%28pi*i%29%2B1

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CVS checkout problems with -D option

Kohsuke Kawaguchi
Administrator
In reply to this post by CletusTSJY

local time <-> UTC conversion is done by JRE, and I don't know exactly
how it does so --- specifically I don't know how JRE figures out the
current time zone.

I first thought maybe it's a printing issue (I saw one person reported
that "18:00" is reported as "6:00" --- missing AM/PM marker), but if
it's 5:30, sounds like it's a time conversion issue.

Can you go to http://server/hudson/systemInfo and check the
"user.timezone" system property and make sure that looks correct?


CletusTSJY wrote:

> Well, perhaps I'm confused.  The "date" command on the server returns 11:00
> AM PDT (which is correct).  The date in the checkout command from hudson
> says "5:30 UTC".  The current time in UTC (according to
> http://tycho.usno.navy.mil/cgi-bin/timer.pl, which I have tested to be
> correct) is 18:00 UTC.  So it seems like Hudson's value is incorrect, unless
> that is not supposed to be the current time and I am misunderstanding the
> tool.
>
> Thanks,
> Cameron
>
>
> Jesse Glick wrote:
>>
>> CletusTSJY wrote:
>>> [cvs up -D is] grabbing a time that is about 13 hours behind.  The
>>> result is that any changes in the last 13 hours don't take affect.
>>> I've checked my server time and it is correct.
>>
>> Perhaps your server admin confused localtime with UTC?
>>
>> -J.
>>
>> --
>> [hidden email]  netbeans.org  ant.apache.org  hudson.dev.java.net
>>              http://google.com/search?q=e%5E%28pi*i%29%2B1
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CVS checkout problems with -D option

Jesse Glick
Kohsuke Kawaguchi wrote:
> local time <-> UTC conversion is done by JRE, and I don't know exactly
> how it does so --- specifically I don't know how JRE figures out the
> current time zone.

Presumably TZ env var on Unix. No idea on WIndows.

> I first thought maybe it's a printing issue (I saw one person reported
> that "18:00" is reported as "6:00" --- missing AM/PM marker), but if
> it's 5:30, sounds like it's a time conversion issue.

Most likely. There are some time zones that use half hour (or even
quarter hour!) increments, but these are unusual.

> Can you go to http://server/hudson/systemInfo and check the
> "user.timezone" system property and make sure that looks correct?

And you can go into Manage Hudson > Script Console and enter

---%<---
d = new java.util.Date()
println(d)
import java.text.DateFormat
df = DateFormat.getDateTimeInstance(DateFormat.FULL, DateFormat.FULL,
java.util.Locale.US)
df.setTimeZone(java.util.TimeZone.getTimeZone("UTC"))
println(df.format(d))
---%<---

For reference, right now on my Hudson installation (run on a Linux
machine set to use UTC) I see the result

---%<---
Thu Aug 30 16:12:12 UTC 2007
Thursday, August 30, 2007 4:12:12 PM UTC
---%<---

-J.

--
[hidden email]  netbeans.org  ant.apache.org  hudson.dev.java.net
             http://google.com/search?q=e%5E%28pi*i%29%2B1

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CVS checkout problems with -D option

CletusTSJY

Jesse Glick wrote
Kohsuke Kawaguchi wrote:
> local time <-> UTC conversion is done by JRE, and I don't know exactly
> how it does so --- specifically I don't know how JRE figures out the
> current time zone.

Presumably TZ env var on Unix. No idea on WIndows.

> I first thought maybe it's a printing issue (I saw one person reported
> that "18:00" is reported as "6:00" --- missing AM/PM marker), but if
> it's 5:30, sounds like it's a time conversion issue.

Most likely. There are some time zones that use half hour (or even
quarter hour!) increments, but these are unusual.

> Can you go to http://server/hudson/systemInfo and check the
> "user.timezone" system property and make sure that looks correct?

And you can go into Manage Hudson > Script Console and enter

---%<---
d = new java.util.Date()
println(d)
import java.text.DateFormat
df = DateFormat.getDateTimeInstance(DateFormat.FULL, DateFormat.FULL,
java.util.Locale.US)
df.setTimeZone(java.util.TimeZone.getTimeZone("UTC"))
println(df.format(d))
---%<---

For reference, right now on my Hudson installation (run on a Linux
machine set to use UTC) I see the result

---%<---
Thu Aug 30 16:12:12 UTC 2007
Thursday, August 30, 2007 4:12:12 PM UTC
---%<---

-J.

--
jesse.glick@sun.com  netbeans.org  ant.apache.org  hudson.dev.java.net
             http://google.com/search?q=e%5E%28pi*i%29%2B1

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@hudson.dev.java.net
For additional commands, e-mail: users-help@hudson.dev.java.net

Thanks for the suggestion on the script, I did it and it reported correct results.  I'm not sure what has happened, but the time is only being reported as about 6 minutes behind now.   So 6 minutes is a relatively painless amount of time to wait before building.  I'm satisfied.

Thanks for all your help!
Loading...