5 ms·

Timezones can change when specified by continent/city too. The bigger problem with three-letter zone names is that they're not unique. I found 3 different def

by mark-r 5y ago

Timezones can change when specified by continent/city too. The bigger problem with three-letter zone names is that they're not unique. I found 3 different definitions of CST for example.

hhebbo 5y ago
another problem with the 3-letter system is that it's not always 3 letters. With daylight saving CST become CEST which is then +-1 different depending where you are. With hTime and bringing UTC into the clock, I'm aiming at eliminating the need to think of the 3-letter system altogether. If I know what time globally is (UTC) and what it means in my local time, then I won't need to know what CET or PT is anymore. hTime gets the job done using "one clock". The idea of UTC here is that it's a rotating UTC. So hTime utilizes where you are on Earth and uses that to rotate UTC accordingly so you get the same reading of time everywhere. That's a global time concept, which what UTC is about.
- mark-r 5y ago
  In the U.S. CST becomes CDT in the summer. Which country changes it to CEST?
  - hhebbo 5y ago
    ah sorry, that's CET (not CST) to CEST. That's Europe Central Time to Europe Central Summer Time. I believe we better off using UTC only.
    - mark-r 5y ago
      I think computers may be better off using UTC, but people are still better off with local time. I'd hate to be at UTC+11 or UTC-11 and have the date change in the middle of the day.
rini17 5y ago
When timezone for a city changes and you store time with timezone name/offset, you won't know. If you store time with location, you are one update of tzdata away from automatically solving the problem.
- mark-r 5y ago
  Except that tzdata doesn't store offset rules for every city. You still need to know which city represents your location, which is just as arbitrary as some random timezone code. Every once in a while zone boundaries or local zone rules change, so what was once your reference city is obsolete.
  - rini17 5y ago
    Sure, not in tzdata, but data as which county is under which timezone certainly must exist somewhere. All I ask to people whom it concerns to sit down and thoughtfully agree how to process location-based local time. Yes storing time like "2021-11-01 10:00 Europe/Warsaw/Łękołody/Chrząszczyrzewoszyce/" souds absurd...but such absurdities have the uncanny tendency to come true and it's good if someone preemptively tries to clear things up.

by mark-r 5y ago

Timezones can change when specified by continent/city too. The bigger problem with three-letter zone names is that they're not unique. I found 3 different definitions of CST for example.

hhebbo 5y ago

another problem with the 3-letter system is that it's not always 3 letters. With daylight saving CST become CEST which is then +-1 different depending where you are. With hTime and bringing UTC into the clock, I'm aiming at eliminating the need to think of the 3-letter system altogether. If I know what time globally is (UTC) and what it means in my local time, then I won't need to know what CET or PT is anymore. hTime gets the job done using "one clock". The idea of UTC here is that it's a rotating UTC. So hTime utilizes where you are on Earth and uses that to rotate UTC accordingly so you get the same reading of time everywhere. That's a global time concept, which what UTC is about.

mark-r 5y ago
In the U.S. CST becomes CDT in the summer. Which country changes it to CEST?
- hhebbo 5y ago
  ah sorry, that's CET (not CST) to CEST. That's Europe Central Time to Europe Central Summer Time. I believe we better off using UTC only.
  - mark-r 5y ago
    I think computers may be better off using UTC, but people are still better off with local time. I'd hate to be at UTC+11 or UTC-11 and have the date change in the middle of the day.

rini17 5y ago

When timezone for a city changes and you store time with timezone name/offset, you won't know. If you store time with location, you are one update of tzdata away from automatically solving the problem.

mark-r 5y ago
Except that tzdata doesn't store offset rules for every city. You still need to know which city represents your location, which is just as arbitrary as some random timezone code. Every once in a while zone boundaries or local zone rules change, so what was once your reference city is obsolete.
- rini17 5y ago
  Sure, not in tzdata, but data as which county is under which timezone certainly must exist somewhere. All I ask to people whom it concerns to sit down and thoughtfully agree how to process location-based local time. Yes storing time like "2021-11-01 10:00 Europe/Warsaw/Łękołody/Chrząszczyrzewoszyce/" souds absurd...but such absurdities have the uncanny tendency to come true and it's good if someone preemptively tries to clear things up.