dadd does not properly validate the time zone

[rdiez]

The following command "succeeds" without any hint about the erroneous time zone:

dateutils.dadd --zone=NonExistingTimeZone now +2h

The same applies to option "--from-zone".

Such a lack of validation is generally bad practice, but this is especially risky, because the time zone designations may vary from system to system. Most time zone designations are pretty stable and will usually work, but one day one will fail, and that error will probably go unnoticed.

This problem was mentioned in passing in #97.

[hroptatyr]

Hi,
thank you for the report. A proposed fix is in a844d56.

[rdiez]

First of all, thanks for your effort.

I wouldn't warn though, I would fail. Otherwise, automated scripts will never realise that the date calculations are wrong. Even human users may be reading the result at the end and miss any warnings above.

If you only want to warn, I would document that, in order to assure reliability, the caller should check that nothing gets written to stderr. Because warnings go to stderr, don't they?

Another alternative would be adding a command-line option named "--strict", "--reliable" or "--consider-warnings-as-failures".

[hroptatyr]

No you're right, it's no good having low-level code interact with the user somehow. 461a944 lifts the check and handling into the tools, and makes an illegal zone a fatal error.

[rdiez]

The new patch seems fine to me.

One minor thing though: I wouldn't use the backtick character ` around %s in error strings like:
Error: cannot find zone specified in --from-zone: `%s'
I would use the standard ASCII apostrophe ' on both sides of %s .

[hroptatyr]

Errors of the form `%s' are needed to allow locales to pick the right quoting character.
Currently, dateutils isn't gettextised but I want to keep this option open.

[rdiez]

OK, then the patch is fine!