Hacker News Reader

One large set of projects is world-wide Ham Radio contests. This gets rid of the time zone problem and the Daylight Time Savings problem, or the British Double Summer War Time problem. And it isn't just the contests--pretty much all of radio timekeeping is done in UTC (formerly called GMT), affectionately known as Zulu, with a 'Z'.

I participated in one expedition to Vanuatu with five other guys from our radio club (the Prairie Dx Group) in which we flew from Chicago. 28 hours of travel to get there. Lost one particular Thursday in the process. We were keeping a web site updated with our results in real time, and had to keep in touch with the webmaster. The event was run on Z time, and the daylight obviously was on local time. So we were tracking three different time zones in an event that ran around the clock, and pretty much had no intuitive sense of what time it was.

But in worldwide radio communication, it is often important to know what the sunrise and sunset times are in the places you hope to communicate with. Many of my friends who are very good at this know this for important locations around the globe for various seasons.

One thing you can do to get used to UTC is to set your wrist watch or the office clock to UTC. You will shortly adjust, or miss dinner.

And as a life-long ham, when I write times, I use four digits: "I am on the 1800 train coming home." Some folks say "wtf", and others you can catch them counting on their fingers.

Eve Online solved that by having an in-game clock which is always set to UTC, then all in-game events are announced in Eve time (sometimes with GMT / PST / etc in brackets); I've not seen anyone complain about the time zones there (though I only hang out in player channels, I don't see the official support tracker :P)

This is what tends to get done with nautical work as well. Every boat has a gps, so every boat has an accurate utc clock.

That said, you don't need GPS to get a UTC clock. EVE Online for example determines the clock drift on connection to the servers by bouncing packets around.

I wish there was something like Swatch Beats for today.

https://en.wikipedia.org/wiki/Swatch_Internet_Time

> Swatch Internet Time (or beat time) is a decimal time concept introduced in 1998 and marketed by the Swatch corporation as an alternative, decimal measure of time. One of the goals was to simplify the way people in different time zones communicate about time, mostly by eliminating time zones altogether.

> Instead of hours and minutes, the mean solar day is divided up into 1000 parts called ".beats". Each .beat lasts 1 minute and 26.4 seconds. Times are notated as a 3-digit number out of 1000 after midnight. So, @248 would indicate a time 248 .beats after midnight representing 248/1000 of a day, just over 5 hours and 57 minutes.

> There are no time zones in Internet Time; instead, the new time scale of Biel Meantime (BMT) is used, based on Swatch's headquarters in Biel, Switzerland and equivalent to Central European Time, West Africa Time, and UTC+1. Unlike civil time in most European countries, Internet Time does not observe daylight saving time.

Yeah, I know what you mean. I run a large gaming website. For tournaments, two or more players have to agree on a time to meet and play.

A dialog goes something like this: Player A: I live in X time zone and 3pm works for me. Player B: OK, I'm in EST, let me see what time that is for me. ... OK, that works!

And then Player A and Player B miss each other, because Player B wasn't aware that his current time zone was EDT, not EST.

Even if both players convert to UTC first it doesn't work, because EST -> UTC and EDT -> UTC yield different times. And it's difficult to help them out with site-mandated time tools, because players like to coordinate over IRC, Twitter, GChat, ...

I'm sure there's a good way to fix this problem, I just feel like I shouldn't have to.

EDIT: I just saw the Eve online comment. Unfortunately that doesn't work quite as well for us, as the game isn't a program that's always running on the player's computers. It's more in the spirit of trying to coordinate chess matches.

Seems like this could be solved on your end with code. Just add a sprinkle of Javascript to detect what timezone they're in and either show them the UCT time or maybe set up a button saying something like "Suggest Time" where the player who clicks it sees the time for their own timezone but the UCT time is sent across so that the other player sees it converted to their own time.

This is a _community_, not a web app. Maybe the two words mean the same thing to people nowadays, but it didn't back in ~1999, when this community was formed--5 years before the website was formed. It's not the case that the website is the central hub for everything. As I said, players sometimes prefer coordinating over IRC or other mediums. And in some cases, there isn't one central place to play matches.

You can certainly mitigate the problem by encouraging people to use a web app to coordinate. Maybe there is an incentive structure that would help drive adoption. But whether or not people use the web app or not, they are still apart of the community and we have to serve them. I don't necessarily decide who is in and who is out.

Anyway, the point of my post wasn't to complain that there aren't workarounds. There are. I just think we as a society _shouldn't have to workaround DST_, and I wanted to add my lend my (largely insignificant) story to the cause.

You could create an IRC bot or client script that recognizes times entered in the channel and converts them to UTC plus a couple of common zones.

>Even with mitigations, my staff and I basically spent every DST start/end dealing with a plethora of IRs to the degree of, "why did you change the time?"

For us the mayhem used to last for weeks because DST changes in different countries at different times. However, the biggest challenge was always to convey to many programmers that despite a date being in different timezones, the UTC timestamp is always the same and that timezone merely changes the interpretation of a UTC timestamp. Than there was the nuisance of different machines running in different timezone and some automatically generated cron jobs all going haywire. And then, any scripts you write to fix the issue have to wait for 6 months before they can be battle tested. It took us a good 3 DST changes to finally solve the problem and still it is quite an unpleasant hack.

No, I would not miss DST either. After all it has been more than a century since light bulb liberated us from relying on the Sun as the sole source of light.

I won't even bother to get into the other countries.

I support a single use device application (running on Palm E2s!) that requires constant fiddling to keep up with DST changes around the globe. In the past, some countries have changed their DST observance mere weeks before it was supposed to happen.

>I won't even bother to get into the other countries.

I live in eastern Canada and even some of my own fellow Canadians don't realize we are an hour ahead of them here in this region.

And east of my region is Newfoundland and Labrador who are 30 minutes ahead of my region.

I work as part of a mostly American dev team, but out of Sydney. We vary between having team meetings at my midnight, which includes the US East, but doesn't include the US West, or 8-9am, which can include the US West but not the east. The former becomes 2am with Aus moving one way and the US East moving the other, at which point I stop having any real contact with the US East.

Yes, but I use the zonetime database that's built into many OSes to handle that. We make people tell us their timezone, but translate it spatially, not into zones. Points in space are sufficient to do actual UTC-to-local translations while "zones" are not. This is what's happening when you see "America/New_York" as your "time zone".

Didn't run a game, but needed to play across time zones for reporting. Stored UTC, Local Time, and Minute Offset[1] for each transaction.

1) why yes, you should be able to do the math from the two dates, but it was more a check and debug thing

Ran into DST problem when I had to build a Gantt chart in flash, project scope just so happen cross the time change while development. I ended up solving the bug but it wasn't fun on bit.

This is one this I'm thankful for in the .Net framework. Give it any datetime in UTC, then give it a time zone and it spits out a local time. There is zero work to do.

While I admit that using a framework instead of your own solution is a good solution, please note that that's not "zero work", it just passes the buck to the client. The framework's knowledge of the timezones still has to be kept up to date. For example, Israel used to have ad-hoc DST times changing each year and "...the unpredictability of IDT in Israel became frustrating enough that Microsoft Windows stopped trying to track changes and just made Israeli time be Greenwich Mean Time plus two hours (GMT+2) (and disabled the daylight saving option). This has led to various ad hoc solutions to the problem in Windows systems and other Microsoft software (e.g. Outlook calendar entries are often off by an hour when shared, due to the lack of IDT support)." [1]

[1]http://en.wikipedia.org/wiki/Israel_Summer_Time

This isn't limited to .Net - any modern standard library offers this feature.

You realize that the tzdb files this functionality depends on has several updates each year that are probably never being installed on 90% of computers?

Yes, of course.

I never get how MMORPGs could consistently get this so wrong time & time again. It always boggles my mind that the Devs could miss putting a simple locale aware date/time picker/presenter into the game and on the website.

Computers can deal with this. Computers have been dealing with this for decades. Your computer knows which locale you are in.

Use the bloody computer.

It's almost like the joke that hardware guys can't program, gaming devs can't make simple forms. Or menus for that matter.

Totally and fundamentally wrong. Better use bloody logic. Server-wide events are meant to start/end in sync. This isn't a plain stupid web form. What if some smart arse switches time zone to have an event earlier and then end later?

Have the events occur at specific absolute times but show the time in the player's time zone. If they switch zones they see different times, not change the behaviour of the game.

Fundamentally wrong? That's a really odd thing to say.

http://en.wikipedia.org/wiki/Coordinated_Universal_Time

It's not complicated, every language has simple code to change a local time to UTC and back again and it's built in to every computer. It's a solved problem.

Most devs who have ever had to deal with dates know to send any user-input to the server with the TZ information attached, to then always store that time in UTC and then translate that for the user, either client-side if you're sending raw data, or asking for a timezone setting and transforming it server-side (if you're sending HTML for example. Browsers, alas, do not tell the server what timezone the request is coming from, which is why all forums ask you for your tz so they can show the correct post time, relative to you).

Apart from, seemingly, game devs.

How on earth do you think the world has been operating without the basic functionality of being able to talk about an explicit, locale neutral time? To translate a TZ specific date/time to another TZ specific date/time? Banking would be buggered.