4 ms·

It is entirely reasonable for a personal server to be set to the timezone it is physically located in.

lionkor 4y ago
I'm no expert, but if your software can't deal with timezones, be worried. So yes, absolutely, it should be perfectly okay to use your local timezone.
- bcrl 4y ago
  Timezones are disaster. Once upon a time it was difficult and time consuming to make changes to them. Then the world began developing more and "accurate" timekeeping devices. Atomic clocks were developed and began to be miniaturized. Then someone had the brilliant that incredibly accurate clocks could be used to determine location. GPS was born. A few decades pass and we now all have highly accurate "clocks" that we carry around in our pockets that receive GPS signals and sync their idea of time to what the satellite thinks. Sounds great, right? Except, humans don't actually use atomic clocks as the basis for their timekeeping. We look outside and expect the time on the clock to mostly match with the position of the sun in the sky. Once leap seconds became entangled in them, the whole thing basically a toxic pile of radioactive waste. Timezones are now being updated multiple times a year since the internet means we can update them at will. The whole thing is now a giant mess of toxic radioactive waste that can never be correct for any extended period of time. We, the software industry, did this to ourselves. We built this, we have to live with it, and it's never going away.
  - fsckboy 4y ago
    computers are good at keeping track of things that humans aren't. tracking timezones is in your computer's wheelhouse, don't be scared of it.
    - bcrl 4y ago
      I'm not scared of it. It's unnecessary excessive complexity that we have foisted onto ourselves. It has caused countless bugs and will most likely cause countless more before I die. Show me the software that copes with timezone changes at runtime.
      - nikau 4y ago
        humans having to convert times from UTC to local timezone will also result in countless hours wasted in troubleshooting.
      - Spivak 4y ago
        Every phone when people travel? It really isn’t that hard. What makes you pull your hair out is dealing with 3rd party code that handles it incorrectly. Do everything internal in UTC or always attach a timezone to dates, your choice. When you cross the boundary either ingesting naive dates or displaying them read the system time zone again and convert. I mean it’s kinda annoying but “naive” times is the time equivalent of storing arrays without their length. I can’t fathom why we even allow it.
  - hnfong 4y ago
    That's what happens when you let a sect of Sun-worshipping astrologers redefine the minute to have up to 61 seconds...
KennyBlanken 4y ago
It shouldn't actually matter. Hardware clocks should usually be in UTC, but the timezone should be "whatever makes sense." Webapps should be timezone aware via the browser or user preferences, internal timezone should be whatever makes sense for logging et al.
oceanplexian 4y ago
Worked at a very big social media company and we set them all to Pacific since that’s where we were located. The servers themselves were physically located in different time zones. There’s no hard and fast rule what TZ’s servers need to be in IMHO.
computerfriend 4y ago
Or the timezone the sole user is primarily located in.
sgarland 4y ago
Generally I agree (mine are in America/New_York), but I did find [0] and fix [1] a weird bug in Debian's cron that only surfaced when I moved. I was in America/Chicago, moved to America/New_York, and then changed TZ on the servers once they were set up. Afterwards, I noticed that a daily cronjob that was supposed to fire at 0845 was instead happening at 0945. [0]: https://gist.github.com/stephanGarland/b7cdd963e0ac53ea42f8ed15e35b193d https://gist.github.com/stephanGarland/b7cdd963e0ac53ea42f8e... [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019716 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019716

I'm no expert, but if your software can't deal with timezones, be worried. So yes, absolutely, it should be perfectly okay to use your local timezone.

bcrl 4y ago
Timezones are disaster. Once upon a time it was difficult and time consuming to make changes to them. Then the world began developing more and "accurate" timekeeping devices. Atomic clocks were developed and began to be miniaturized. Then someone had the brilliant that incredibly accurate clocks could be used to determine location. GPS was born. A few decades pass and we now all have highly accurate "clocks" that we carry around in our pockets that receive GPS signals and sync their idea of time to what the satellite thinks. Sounds great, right? Except, humans don't actually use atomic clocks as the basis for their timekeeping. We look outside and expect the time on the clock to mostly match with the position of the sun in the sky. Once leap seconds became entangled in them, the whole thing basically a toxic pile of radioactive waste. Timezones are now being updated multiple times a year since the internet means we can update them at will. The whole thing is now a giant mess of toxic radioactive waste that can never be correct for any extended period of time. We, the software industry, did this to ourselves. We built this, we have to live with it, and it's never going away.
- fsckboy 4y ago
  computers are good at keeping track of things that humans aren't. tracking timezones is in your computer's wheelhouse, don't be scared of it.
  - bcrl 4y ago
    I'm not scared of it. It's unnecessary excessive complexity that we have foisted onto ourselves. It has caused countless bugs and will most likely cause countless more before I die. Show me the software that copes with timezone changes at runtime.
    - nikau 4y ago
      humans having to convert times from UTC to local timezone will also result in countless hours wasted in troubleshooting.
    - Spivak 4y ago
      Every phone when people travel? It really isn’t that hard. What makes you pull your hair out is dealing with 3rd party code that handles it incorrectly. Do everything internal in UTC or always attach a timezone to dates, your choice. When you cross the boundary either ingesting naive dates or displaying them read the system time zone again and convert. I mean it’s kinda annoying but “naive” times is the time equivalent of storing arrays without their length. I can’t fathom why we even allow it.
- hnfong 4y ago
  That's what happens when you let a sect of Sun-worshipping astrologers redefine the minute to have up to 61 seconds...

KennyBlanken 4y ago

It shouldn't actually matter. Hardware clocks should usually be in UTC, but the timezone should be "whatever makes sense." Webapps should be timezone aware via the browser or user preferences, internal timezone should be whatever makes sense for logging et al.

oceanplexian 4y ago

Worked at a very big social media company and we set them all to Pacific since that’s where we were located. The servers themselves were physically located in different time zones. There’s no hard and fast rule what TZ’s servers need to be in IMHO.

computerfriend 4y ago

Or the timezone the sole user is primarily located in.

sgarland 4y ago

Generally I agree (mine are in America/New_York), but I did find [0] and fix [1] a weird bug in Debian's cron that only surfaced when I moved. I was in America/Chicago, moved to America/New_York, and then changed TZ on the servers once they were set up. Afterwards, I noticed that a daily cronjob that was supposed to fire at 0845 was instead happening at 0945. [0]: https://gist.github.com/stephanGarland/b7cdd963e0ac53ea42f8ed15e35b193d https://gist.github.com/stephanGarland/b7cdd963e0ac53ea42f8e... [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019716 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019716