SF YAML time parsing error about demystify HOT 2 CLOSED

Ah, of course the second I step away for a second I realize what's going on in SFHandlerClass.py:

def getYear(self, datestring):
      #sf example: 2016-04-02T20:45:12+13:00
      datestring = datestring.replace('Z', '') #TODO: Handle 'Z' (Nato: Zulu) time (ZIPs only?)
      dt = datetime.datetime.strptime(datestring.split('+', 1)[0], '%Y-%m-%dT%H:%M:%S')
      return int(dt.year)

dt is splitting the time zone info on +, but in this case the timezone code actually starts with a '-', not a '+'.

The following seems to work, although it does introduce another dependency (namely, dateutil.parser):

   def getYear(self, datestring):
      #sf example: 2016-04-02T20:45:12+13:00
      datestring = datestring.replace('Z', '') #TODO: Handle 'Z' (Nato: Zulu) time (ZIPs only?)
      dt = dateutil.parser.parse(datestring)
      return int(dt.year)

from demystify.

Hi Tim,

Thanks for this! It's great! And thanks for going the extra step of isolating the issue.

Rather than put in another dependency I've opted to create a unit test for two date handling functions, as well as return 'NULL' when there's a problem retrieving the date. At least the script now should output something useful without failing.

I've placed a try/except in the code as well as a final backup of treating the date as a string.

It feels quite hacky and wish Python's native support was stronger but I hope these look okay for you.

Please let me know what you think of the overall output, and performance once you've got it up and running okay.

(I've also spotted an error with the --export flag in droidsqliteanalysis.py at the same time. You can run droidsqliteanalysis.py --export to avoid having to run droid2sqlite.py as well)

Cheers,

Ross

from demystify.