clock: add unset functionality

[RustyBower]

Description

Adds functionality for user to unset their timezones if desired

Checklist

• I have read CONTRIBUTING.md
• I can and do license this contribution under the EFLv2
• No issues are reported by make qa (runs make quality and make test)
• I have tested the functionality of the things this change touches

[dgw]

ctz? tf/ctf?

[dgw]

What about .unsetctf?

Also musing that maybe it's less awkward to call these "clear" instead of "unset". My mental jury is still out on whether to put that before or after the type (e.g. .tzclear vs. .cleartz).

[half-duplex]

Personally, where a command can be reused without making it too confusing, I prefer that over a new command. .settz - or .settz none?

[RustyBower]

Personally, where a command can be reused without making it too confusing, I prefer that over a new command. .settz - or .settz none?

I disagree, I really try to avoid overloading a command where possible, and to @dgw's question, .settz and .unsettz are natural opposites, versus something like .tzclear which is antithetical to the format for .settz

We also use .unset X repeatedly throughout the codebase, so I'd prefer to stay consistent there

[dgw]

Welp, I can't laugh at "sorry, misclicked" people any more. Touchpads are something else…

Rusty's points are well taken, and I'm just stuck on the missing .unsetchanneltf command now.

[half-duplex]

Eh... Personally, I'd still rather one if in the .setX than polluting .help by adding another four commands.
I only see one other '.unset*' command, and it's in admin.py for unsetting a config option, where 'none'/'-'/etc would potentially be valid values for .set.

[RustyBower]

Good spot @dgw :)

[RustyBower]

Eh... Personally, I'd still rather one if in the .setX than polluting .help by adding another four commands.
I only see one other '.unset*' command, and it's in admin.py for unsetting a config option, where 'none'/'-'/etc would potentially be valid values for .set.

I'll defer to @dgw on this, since he has to maintain this, but personally, I am adamantly against overloading commands (especially a set command with unset functionality) to have complex usage logic, rather than having a few extra commands in help.

[dgw]

I'll approve this as-is. @RustyBower please just squash to one commit.

If we're going to have the argument about overloaded vs. separate commands, it should be held separately—and if overloading wins, we'd have to rework the .get* commands in here too. Most likely overloaded command usage would be .setThing value (set), .setThing (get, no argument), and .setThing - (unset, whether it's - or something more verbose). But this is already too much about that line of reasoning.

[RustyBower]

I'll approve this as-is. @RustyBower please just squash to one commit.

Done

[dgw]

Wait a minute, what's this Unix file-mode change?

[RustyBower]

Wait a minute, what's this Unix file-mode change?

Fixed