Remove constCast in Timezone.deinit

[Ratakor]

Closes #32

create a Timezone, set it to a Datetime, de-initialize it, and overwrite it with a new one

I think that it is fine to say that this is undefined behavior since Datetime takes a pointer to a Timezone so it implicitely means that Timezone should live as long as Datetime for it to be correct.

Also, having const Timezone doesn't prevent this footgun: create a Timezone, set it to a Datetime, and de-initialize. This result in a wrong offset too.

---

This change also prevents from doing

zdt.Timezone.UTC.deinit();

which I don't know why someone would do that but it will result in a segfault with current behavior.

[FObersteiner]

I think that it is fine to say that this is undefined behavior since Datetime takes a pointer to a Timezone so it implicitely means that Timezone should live as long as Datetime for it to be correct.

Right, good point! So let's go with the Timezone being a 'var'. Since deinit modifies it, this is more idiomatic IMHO.

---

This result in a wrong offset too.

are you sure? To my understanding, de-initializing the tz should not alter the offset; added a check to

zdt/tests/test_timezone.zig

Line 61 in b5d3204

test "tz deinit is mem-safe" {

[Ratakor]

I got another idea to make Timezone constant while preventing from freeing UTC, it's basically to remove the clearing of __name_data and tzinfo which is fine since using something deinitialized is almost always an undefined behavior. I don't know if it's worth making another PR about the same subject so you can check the changes here master...Ratakor:zdt:master.

[FObersteiner]

tz deinit
In pub fn deinit(tz: Timezone) void {, I wonder if tz is actually passed by reference under the hood, because at the moment, the Zig compiler may decide to do so if you don't explicitly specify pass-by-pointer [docs]. Put the other way around, if tz was passed by value here, i.e. copied, deinit should have no effect outside of the function, no?
I'm not sure if this applies here, but I know that there has been quite some discussion (e.g. here) around it because it can lead to incorrect results.

POSIX TZ
I saw you added a posix.zig file :) Was just thinking how to proceed with this, it's a feature I would appreciate to have in the lib, however I know from a contribution to https://github.com/leroycep/zig-tzif that it's a bit of a hassle to write a good parser.