pcp
[Top] [All Lists]

Re: [pcp] qa/737 - need some Python help

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: Re: [pcp] qa/737 - need some Python help
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Tue, 22 Mar 2016 02:37:41 -0400 (EDT)
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <56F09F68.5080809@xxxxxxxxxxxxxxxx>
References: <56F064F6.1030209@xxxxxxxxxxxxxxxx> <56F09F68.5080809@xxxxxxxxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: EvQvxpyFLMBGo8693JcjWN8GdqCDzQ==
Thread-topic: qa/737 - need some Python help
Hi Ken,

----- Original Message -----
> On 22/03/16 08:17, Ken McDonell wrote:
> [...]
>          inseconds = 0.0
>          try:
>              inseconds = time.mktime(timetuple)
>          except:
>              pass
>          return "%s %s" % (inseconds.__str__(), timetuple)
> 
> I don't see the point of this ... inseconds can _never_ be anything
> useful, as it will be constructed using the _local_ timezone, not the
> PMAPI TimeZone.  And indeed this number is the value above for all hosts
> in Melbourne, but something quite different for grundy.sgi.com in the USA.

Yep, not sure why its not using __pmMktime(3) ... looking again, I suspect
that was the intent rather than the python time call there.

> Why don't we skip all the inseconds stuff and simply
> 
>       return str(timetuple)

That would give a string like "(2003, 02, 3, ...)" and not a timestamp in
the mktime form we were after I guess.

>  > and why is str(..) needed in the first case, but not the second?
> 
> and I still have no clue on this.
> 

Not sure either, I'll dig deeper on both fronts tomorrow.

cheers.

--
Nathan

<Prev in Thread] Current Thread [Next in Thread>