Hardening/460 date format in parse args

### Description
One-liner to fix the issue #460
It seems that with that log line, the `-t 0-255` is ignored. This is the startup log, based on this code:

```
time=2014-07-25T18:59:46.521CEST | lvl=INFO | trans=N/A | function=main | comp=Orion | msg=contextBroker.cpp[1218]: Orion Context Broker is running
time=2014-07-25T18:59:46.525CEST | lvl=INFO | trans=N/A | function=mongoConnect | comp=Orion | msg=MongoGlobal.cpp[122]: Successful connection to database
time=2014-07-25T18:59:46.525CEST | lvl=INFO | trans=N/A | function=mongoInit | comp=Orion | msg=contextBroker.cpp[1055]: Connected to mongo at localhost:orion
time=2014-07-25T18:59:46.526CEST | lvl=INFO | trans=N/A | function=recoverOntimeIntervalThreads | comp=Orion | msg=MongoGlobal.cpp[421]: Database Operation Successful ({ conditions.type: "ONTIMEINTERVAL" })
time=2014-07-25T18:59:46.526CEST | lvl=INFO | trans=N/A | function=main | comp=Orion | msg=contextBroker.cpp[1291]: Startup completed
[fermin@centollo fiware-orion]$ tail -f /tmp/contextBroker.log
time=2014-07-25T18:59:46.521CEST | lvl=INFO | trans=N/A | function=main | comp=Orion | msg=contextBroker.cpp[1218]: Orion Context Broker is running
time=2014-07-25T18:59:46.525CEST | lvl=INFO | trans=N/A | function=mongoConnect | comp=Orion | msg=MongoGlobal.cpp[122]: Successful connection to database
time=2014-07-25T18:59:46.525CEST | lvl=INFO | trans=N/A | function=mongoInit | comp=Orion | msg=contextBroker.cpp[1055]: Connected to mongo at localhost:orion
time=2014-07-25T18:59:46.526CEST | lvl=INFO | trans=N/A | function=recoverOntimeIntervalThreads | comp=Orion | msg=MongoGlobal.cpp[421]: Database Operation Successful ({ conditions.type: "ONTIMEINTERVAL" })
time=2014-07-25T18:59:46.526CEST | lvl=INFO | trans=N/A | function=main | comp=Orion | msg=contextBroker.cpp[1291]: Startup completed
```
Compared with the output in https://github.com/telefonicaid/fiware-orion/issues/460, I should get two DEBUG lines. Moreover, sending request to CB (eg. /version) doesn't produce any DEBUG line.

Not sure if this is related with this PR or was introduced in a previous one (comenting out the new line doesn't remove the problem), but this PR is probably the best place to fix :)