3 ms·

There are definitely inconveniences with timezones (believe me, I know); but this would be worse. The political nightmare of convincing the non-British part of

by jtheory 12y ago

There are definitely inconveniences with timezones (believe me, I know); but this would be worse. The political nightmare of convincing the non-British part of the world that "sorry, your day of the week is going to switch in the middle of the afternoon", for example, hasn't even been mentioned yet. Some of those places might not be keen on having their clocks running on British time. To put it mildly. And honestly, the inconveniences aren't hard to work around. If you work across timezones, you figure it out pretty quickly. I work on London time, but live in Central European time; I just talk normally in London time when I'm at work. If we're scheduling something in a timezone-disparate group, I always say "2pm London time" and optionally add in "6:30pm Bangalore time" or whatever is needed. It's only daylight savings that gets annoying, because it changes the offsets. If I've done this bit of simple arithmetic wrongly -- hey, it can happen -- the problem is revealed when I send out meeting requests. Everyone using standard calendar software on their computers (Outlook, Google calendar, whatever) sees the meeting in their local timezone (because of course meeting requests include tz offset info!), so before they actually accept the meeting request, they'll know I've done it wrongly.

coldtea 12y ago
>And honestly, the inconveniences aren't hard to work around. If you work across timezones, you figure it out pretty quickly. Spoken like someone who has never dealt with computing time.
- jtheory 12y ago
  Timezones in computing are an annoyance to solve properly, once, and then always use that code. Use a library of timezones maintained by someone else (in the OS, the VM, or similar), because these need to include the history of timezone changes to be complete, and countries continue to change their timezones, daylight savings rules, etc.. I'd dearly appreciate it if everyone got rid of daylight savings time, but it's abstracted away for almost all applications now. For most purposes, you can store all times in UTC in the database, and let people choose the timezone they want to use for data entry and display. Sometimes you also need to store the "local time" -- e.g., imagine you'll need to generate reports on some stat between 9am and 10am local time, for locations in many timezones -- but always store UTC first. Building the dropdown list people will use to choose their timezone is probably the most annoying part of it. It's hard to come with something that's complete without having terrible usability.
  - manicdee 12y ago
    Even then, you can make a good approximation to their actual timezone using IP geolocation. Then there are the pseudo-dropdowns where the user starts typing their city name (or a prominent city in their timezone) and you look it up on the fly. And then you package that control up as a module to share with other projects that you write :)
- manicdee 12y ago
  Spoken like someone who has never learned to set computers to UTC, and insists on writing their own date/time libraries from scratch. If you think timezones are annoying, wait until you discover leap years and leap seconds!
  - coldtea 12y ago
    Spoken like someone who doesn't understand the complexity and untrustiness of NTP and time synchronization, and is naive enough to think setting the computer to UTC is the end of the story...
kybernetikos 12y ago
> The political nightmare of convincing the non-British part of the world that "sorry, your day of the week is going to switch in the middle of the afternoon", for example, hasn't even been mentioned yet. This is the main real objection. My solution for UIT (http://kybernetikos.github.io/UIT http://kybernetikos.github.io/UIT) was to have two different kinds of day, the international day, which switches at .0 UIT and goes nullday, unday, duoday, triday, quadday, pentday, hexday, heptday, octday and nonday, and the local day which switches at local solar midnight (modulo DST) and goes sunday, monday, tuesday, wednesday, thursday, friday, saturday. The clockface shows when they both change, so it's not too difficult in use. Point being, when someone says "Lets meet on IRC at .4:20 21st Nonday" it refers to a particular time in a year anywhere in the world unambiguously (the 219th day of the year, zero indexed). It's pretty inelegant, but the idea is you would use the local day names when talking to people in the same place as you, and the international days when arranging something with someone physically separated from you.

by jtheory 12y ago

coldtea 12y ago

>And honestly, the inconveniences aren't hard to work around. If you work across timezones, you figure it out pretty quickly. Spoken like someone who has never dealt with computing time.

jtheory 12y ago
Timezones in computing are an annoyance to solve properly, once, and then always use that code. Use a library of timezones maintained by someone else (in the OS, the VM, or similar), because these need to include the history of timezone changes to be complete, and countries continue to change their timezones, daylight savings rules, etc.. I'd dearly appreciate it if everyone got rid of daylight savings time, but it's abstracted away for almost all applications now. For most purposes, you can store all times in UTC in the database, and let people choose the timezone they want to use for data entry and display. Sometimes you also need to store the "local time" -- e.g., imagine you'll need to generate reports on some stat between 9am and 10am local time, for locations in many timezones -- but always store UTC first. Building the dropdown list people will use to choose their timezone is probably the most annoying part of it. It's hard to come with something that's complete without having terrible usability.
- manicdee 12y ago
  Even then, you can make a good approximation to their actual timezone using IP geolocation. Then there are the pseudo-dropdowns where the user starts typing their city name (or a prominent city in their timezone) and you look it up on the fly. And then you package that control up as a module to share with other projects that you write :)
manicdee 12y ago
Spoken like someone who has never learned to set computers to UTC, and insists on writing their own date/time libraries from scratch. If you think timezones are annoying, wait until you discover leap years and leap seconds!
- coldtea 12y ago
  Spoken like someone who doesn't understand the complexity and untrustiness of NTP and time synchronization, and is naive enough to think setting the computer to UTC is the end of the story...

kybernetikos 12y ago

> The political nightmare of convincing the non-British part of the world that "sorry, your day of the week is going to switch in the middle of the afternoon", for example, hasn't even been mentioned yet. This is the main real objection. My solution for UIT (http://kybernetikos.github.io/UIT http://kybernetikos.github.io/UIT) was to have two different kinds of day, the international day, which switches at .0 UIT and goes nullday, unday, duoday, triday, quadday, pentday, hexday, heptday, octday and nonday, and the local day which switches at local solar midnight (modulo DST) and goes sunday, monday, tuesday, wednesday, thursday, friday, saturday. The clockface shows when they both change, so it's not too difficult in use. Point being, when someone says "Lets meet on IRC at .4:20 21st Nonday" it refers to a particular time in a year anywhere in the world unambiguously (the 219th day of the year, zero indexed). It's pretty inelegant, but the idea is you would use the local day names when talking to people in the same place as you, and the international days when arranging something with someone physically separated from you.