Fix and update timezone default and doc

[michaelortmann]

Found by: https://github.com/thommey and https://github.com/dchmelik
Patch by: https://github.com/michaelortmann
Fixes: #461 and #1831

One-line summary:
Fix and update timezone default and doc

Additional description (if needed):

Test cases demonstrating functionality (if applicable):
Test 1
myeggdrop.conf:

#set timezone "America/New_York"
#set env(TZ) "$timezone"

Local time is now 02:53
Test 2
myeggdrop.conf:

set timezone "America/New_York"
set env(TZ) "$timezone"

Local time is now 20:55

[michaelortmann]

@thommey: This fix is similar to what you ask in issue #461, but not quite the very same. I aim to fix both Issues with this PR. $timezone is used in scripts. In the ones we ship by default:

eggdrop/scripts/ques5.tcl

Lines 366 to 367 in d317ac2

	if {![info exists timezone]} {
	set timezone [clock format 0 -format %Z]

I was thinking about switching the timezone and env settings in eggdrop.conf:
instead of:

#set timezone "Europe/Berlin"
#set env(TZ) "$timezone"

we could:

#set env(TZ) "Europe/Berlin"
# Set variable timezone for tcl scripts. This variable is deprecated and will be removed in a future release.
#set timezone $env(TZ)

But then i realized, if users only want to set the timezone variable and not the env(TZ) this make sthings more complicated for them.
So my new proposal is:

# Variable timezone for tcl scripts is deprecated and will be removed in a future release. So in a future release set env(TZ) "Europe/Berlin" directly instead.
#set timezone "Europe/Berlin"
#set env(TZ) "$timezone"

And when we later remove variable timezone, we patch ques5.tcl to use env(TZ) directly.
I hope someone comes up with a better doc wording here.

[vanosg]

Playing with the pre-PR version, I just noticed this interesting timestamp gem:

[13:50:32] TLS: handshake successful. Secure connection established.
[13:50:32] Connected to testnet.foo.chat
[18:50:33] CAP: Current negotiations with testnet.foo.chat: message-tags sasl userhost-in-names

[michaelortmann]

@vanosg this bug also exists in branch develop, its not a PR bug. anyway. took me a while to find and fix this bug. but here we are :) ready for review again!

[vanosg]

I understand the terminology basis for changing the value of the timezone config setting, but how will this affect old non-updated configs being used after this change is made?

[michaelortmann]

if an old config is used, it will work as before
For example the following config will work as before:

set timezone "EST"
set offset "5"
set env(TZ) "$timezone$offset"

[thommey]

@vanosg this removes the offset Tcl variable - do you think that is an issue?

Otherwise I much prefer this approach with timezone names instead of manually figuring out offets unnecessarily.

[vanosg]

@vanosg this removes the offset Tcl variable - do you think that is an issue?

Otherwise I much prefer this approach with timezone names instead of manually figuring out offets unnecessarily.

I have always hated how Eggdrop handles timezones- offset was added for scripting only. Taking it out could cause issues? Maybe we just hardcode it to 0 in the codebase so nothing crashes, and implement this one as part of 1.11.0?

[michaelortmann]

if tcl scripts use "offset" they would change behaviour, but they should not crash because offset was always just a tcl variable set in eggdrop.conf so scripts could never depend on its existence. to not break behaviour of tcls, we could (maybe should?) calculate and set the tcl variable offset based on the set timezone. this would be nice, wouldnt it?

[michaelortmann]

also, static offsets (like we currently have in eggdrop.conf) are not a worse alternative to timezone names, they are not equivalent/static. many timezones have different offsets throughout the year. no one should be damned to update offset manually to stay synced to their timezone.

due to changing offsets, we can argue that the idea of using offset in tcls was borked and never really worked all time anyway. therefore removing offset alltogether is justified. what do you say? calculate and set offset whenever timezone is set/changed or remove it?