More code clean up.

These files are missing unit tests:
 + plaso/frontend/pinfo.py + plaso/frontend/preg.py + plaso/frontend/utils.py + plaso/output/elastic.py
  

Requires: 89320044

[kiddi, 2014-04-23 21:47:52]

Few comments.

https://codereview.appspot.com/89590043/diff/1/plaso/frontend/psort_test.py
File plaso/frontend/psort_test.py (right):

https://codereview.appspot.com/89590043/diff/1/plaso/frontend/psort_test.py#n...
plaso/frontend/psort_test.py:116: self.first =
timelib_test.CopyStringToTimestamp('2012-07-24 21:45:24')
should we not have this as an ISO timestamp?

2012-07-24T21:45:24+00:00

https://codereview.appspot.com/89590043/diff/1/plaso/lib/timelib.py
File plaso/lib/timelib.py (right):

https://codereview.appspot.com/89590043/diff/1/plaso/lib/timelib.py#newcode550
plaso/lib/timelib.py:550: def StringToDatetime(
is this your only change to this file? (besides the default value for
copytoiso)?

https://codereview.appspot.com/89590043/diff/1/plaso/lib/timelib_test.py
File plaso/lib/timelib_test.py (right):

https://codereview.appspot.com/89590043/diff/1/plaso/lib/timelib_test.py#newc...
plaso/lib/timelib_test.py:56: year = int(time_string[0:4], 10)
why not use the timelib..... fromtimestring method?

[Joachim Metz, 2014-04-24 04:13:20]

https://codereview.appspot.com/89590043/diff/1/plaso/frontend/psort_test.py
File plaso/frontend/psort_test.py (right):

https://codereview.appspot.com/89590043/diff/1/plaso/frontend/psort_test.py#n...
plaso/frontend/psort_test.py:116: self.first =
timelib_test.CopyStringToTimestamp('2012-07-24 21:45:24')
On 2014/04/23 21:47:53, kiddi wrote:
> should we not have this as an ISO timestamp?
> 
> 2012-07-24T21:45:24+00:00
We could support both, IMO the version without T is more readable.
The idea is to remove the date command comments.

https://codereview.appspot.com/89590043/diff/1/plaso/lib/timelib.py
File plaso/lib/timelib.py (right):

https://codereview.appspot.com/89590043/diff/1/plaso/lib/timelib.py#newcode550
plaso/lib/timelib.py:550: def StringToDatetime(
On 2014/04/23 21:47:53, kiddi wrote:
> is this your only change to this file? (besides the default value for
> copytoiso)?

That and renaming zone= to timezone= to make it more consistent.

https://codereview.appspot.com/89590043/diff/1/plaso/lib/timelib_test.py
File plaso/lib/timelib_test.py (right):

https://codereview.appspot.com/89590043/diff/1/plaso/lib/timelib_test.py#newc...
plaso/lib/timelib_test.py:56: year = int(time_string[0:4], 10)
On 2014/04/23 21:47:53, kiddi wrote:
> why not use the timelib..... fromtimestring method?

The idea is that the test function does not rely on timelib, since it is used to
test timelib.

[Joachim Metz, 2014-04-24 19:07:33]

Code updated.

[Joachim Metz, 2014-04-24 19:08:18]

Synced with head.

[Joachim Metz, 2014-04-24 21:04:43]

Code updated.

[kiddi, 2014-04-25 16:09:52]

one comment. I vote to move this function out of timelib_test.py and into a
separate test library (or an already existing one)

https://codereview.appspot.com/89590043/diff/1/plaso/frontend/psort_test.py
File plaso/frontend/psort_test.py (right):

https://codereview.appspot.com/89590043/diff/1/plaso/frontend/psort_test.py#n...
plaso/frontend/psort_test.py:116: self.first =
timelib_test.CopyStringToTimestamp('2012-07-24 21:45:24')
ok, ACK...

On 2014/04/24 04:13:20, Joachim Metz wrote:
> On 2014/04/23 21:47:53, kiddi wrote:
> > should we not have this as an ISO timestamp?
> > 
> > 2012-07-24T21:45:24+00:00
> We could support both, IMO the version without T is more readable.
> The idea is to remove the date command comments.

https://codereview.appspot.com/89590043/diff/40001/plaso/lib/timelib_test.py
File plaso/lib/timelib_test.py (right):

https://codereview.appspot.com/89590043/diff/40001/plaso/lib/timelib_test.py#...
plaso/lib/timelib_test.py:61: month = int(time_string[5:7], 10)
should we rather do a .split()

and then double check that len(split_results[0]) == 10 ???

and then do this on split_results[0]

this approach makes the function quite a lot dependent on an exact date
format... which may be fine since this is solely used in tests, but still.

and another thing... since you are importing this to other test files, which
need to use this function I don't think it makes sense to define this here, you
are then always importing timlib_test, so importing one test file into another.
Instead of having this function defined in a test_lib that is then loaded by all
the other tests....

[Joachim Metz, 2014-04-26 18:06:37]

https://codereview.appspot.com/89590043/diff/40001/plaso/lib/timelib_test.py
File plaso/lib/timelib_test.py (right):

https://codereview.appspot.com/89590043/diff/40001/plaso/lib/timelib_test.py#...
plaso/lib/timelib_test.py:61: month = int(time_string[5:7], 10)
On 2014/04/25 16:09:53, kiddi wrote:
> should we rather do a .split()
> 
> and then double check that len(split_results[0]) == 10 ???
> 
> and then do this on split_results[0]
> 
> this approach makes the function quite a lot dependent on an exact date
> format... which may be fine since this is solely used in tests, but still.
> 
> and another thing... since you are importing this to other test files, which
> need to use this function I don't think it makes sense to define this here,
you
> are then always importing timlib_test, so importing one test file into
another.
> Instead of having this function defined in a test_lib that is then loaded by
all
> the other tests....

I kept the function simple because it is a test function. Yes a split is
possible, but I don't see any advantage. 

I did not put it into the general test_lib since I wanted to keep the timelib
test function with timelib; in case we might reuse it in  dfvfs or other places.

[kiddi, 2014-04-28 15:40:22]

LGTM

after discussion

[Joachim Metz, 2014-04-28 15:51:20]

Code Submitted.