Re: Cassowary failing to report the results back to the - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Cassowary failing to report the results back to the
Date
Msg-id 45056608.4090802@dunslane.net
Whole thread Raw
In response to Re: Cassowary failing to report the results back to the farm  ("Adrian Maier" <adrian.maier@gmail.com>)
List pgsql-hackers
Adrian Maier wrote:
> On 9/11/06, Jeremy Drake <pgsql@jdrake.com> wrote:
>> On Mon, 11 Sep 2006, Adrian Maier wrote:
>>
>> > It's not clear  to me where does that date-in-the-future come from.
>> > The machine's
>> > date is set correctly:
>> > $ date
>> > Mon Sep 11 11:00:30 PST 2006
>>
>> Um, no.  I am currently in the PST time zone, and I can say from
>> first-hand experience that the current time is 2:21 am, not 11 am.  I 
>> have
>> confirmed this by looking out the window and noticing a distinct lack of
>> light.  The time you have quoted is about 8.5 hours in the future.
>> Suggest you either verify your time zone, or look out your window
>> ;)
>
> Thanks Jeremy,
> You are right,  I hadn't realised that 'PST'  indicates a timezone
> (the wrong one..).
> I'll have to change the timezone to GMT+2   .
>
> Sorry for the noise !
>

FYI, the buildfarm scripts all ignore timezone completely. All time 
calculations are done in terms of UTC (a.k.a. GMT for these purposes). 
The result you saw was from some sanity checks built into the web app.

All machines that report buildfarm results should run an NTP client or 
some equivalent means of keeping the system clock reasonably accurate. 
NTP clients are available for every platform we support (including Windows).

If you want to see the UTC time setting, give the command: date -u

cheers

andrew


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fixed length data types issue
Next
From: Gregory Stark
Date:
Subject: Emacs local vars at the tail of every file