Add better support for timezones about tempus HOT 2 CLOSED

Hi,

There is another issues related that is bothering me lately.

Summer time.
Spain is GMT+1, but in summer is like GMT+2

So now I have some dates with the 25 hours, and the countdowns ends because the day is not updated properly...

I prefer the second method. So i will try it

from tempus.

Having explored each of these in depth, here are the disadvantages for each (respectively). I still think style 3 is the one to go for but it comes a pretty big price.

1. This way of doing it is pretty crap, a private is called on pretty much all methods, adding size to the codebase, and the method itself has to be pretty comprehensive, doing lots of ops to correct timezone misshaps (needs to check for rollover minutes, hours, days, months, years). This is also probably the worst for performance.
2. Extra ops for each type of date leads to a lot of code. It essentially doubles the codebase, which is pretty depressing. It also creates code where it is difficult to assert which date to use.
3. So far what I've done with this has the least impact to code size and performance, and it seems more reliable, but it has a massive side-effect: the dates do not automatically adjust to DST. While dates with manual tzs shouldn't, if you're setting tz to locale then it should track DST changes. So maybe use this method, plus a load of code to check if we're using locale timezone, and if so track DST tz changes?

from tempus.