I’m involved in the development of an addon for the Classic WoW versions (Questie), and the thing I do there is such a convoluted process that not doing it feels like letting my fellow devs and the users down. But you can do development on the PTRs and beta servers, so I haven’t given money to Blizzard in a long time. Now you could argue that this is even worse in regards to supporting Blizzard than just paying for a game, but I rationalise it to myself with the fact that the newer clients will inevitably be used for private servers just like the old ones were (some already are actually).

Neither. Battle.net is Blizzards game launcher and store. They also own that domain, but the name usually refers to the binary.

The WINE_SIMULATE_WRITECOPY=1 %command% is the Steam launch option you set, with %command% meaning roughly “what Steam would do without any launch options set”.

The whole process was a bit finicky and I did it a few month ago, but from what I remember it went something like this:

• Download battle.net installer
• Add it as non-Steam game to run it
• Locate the newly created prefix in Steam directory
• Add the Battle.net.exe in it as a non-Steam game, then remove the installer (not the other way around or the prefix will be deleted)

Oh so that’s what you meant. Thought you meant don’t use Lutris at first because of how you worded it. That makes much more sense.

AFAIK you can set Lutris up to use GE or Proton builds.

Did that too a while back, but anecdotally it feels lees buggy through Steam, especially regarding updates.

Also clicking the Stop button in Steam doesn’t leave behind zombie processes off Battle.net.exe and Agent.exe, which I had to manually kill when using Lutris. Assume that’s due to Protons(?) pressure-vessel thingy.

It seems like it would be a bit confusing, though, if you had to relearn times whenever you travel somewhere (edit: and dates could flip over in the middle of a work day). But maybe you’d prefer that.

I’d prefer that over having to change clocks when you travel, and having to have knowledge about the location and possibly having to flip the date when you encounter a reference to a specific time, yes.

Before they were invented, it was literally just anarchy. People set it to match people they knew. That’s what I was thinking of, but it could also just be one place where noon is at 12:00 PM.

Yes, you would obviously do the latter. No sense it going back to the bad old days.

Well, there’s not a round number of second in a day, or days in a year, for example, since they’re all naturally occurring and arbitrary.

Days in a year ok (except leap years). But seconds in a day are round (discounting days with leap seconds). 24 * 60 * 60 = 86400, which is divisible by two. Did you mean they are not based on the decimal system? I’d be up for a decimal based time system and a reorganised calendar, but that wasn’t the topic of discussion here.

And then the Earth turns at a subtly non-constant rate, and people have settled on a seven day week.

Yeah but none of that has much impact on the timezone debate.

If you do have timezones, it doesn’t make sense to be inflexible with them when they run up against geography or trade and cultural ties, so they’ll be curvy, and geopolitics will itself change over decades and someone will want to change which one they’re in.

Fair enough. I acknowledged this point in my other post, that there are historical reasons for timezones mostly rooted in administrative requirements. But I don’t think this is a good reason to not adopt a better system per se.

All of this is a headache if you just want to do a calendar calculation.

Exactly! So out with the old, in with the new. Sure this will create some other headaches, especially given how deeply rooted some of the relevant nomenclature is in most languages, but the sooner we change this the less it will hurt. I see that it might be a non-starter given the inertia and disunity of globalised society working against it, but it still seems desirable nonetheless, to me at least.

I don’t think you could ever change my mind.

Fair enough, I still think you’d get used to it if it were to happen.

And when it does happen it’s usually clarified. In more automated contexts (e.g. a scheduled YouTube premiere) the software converts it automatically - the author inputs the date and time in their own timezone, and viewer sees the converted date and time in their own timezone.

My point exactly though, this is a whole lot of complexity we could just get rid of by using a single timezone, with the added benefit of that working without any automation or clarification. Next Tuesday 14:00? Same time for everybody, regardless of locality. Everyone will know what part of the solar day that is for them by habit.

When it does happen it reminds us that the date and time falls on a different time of day for different participants.

The complexity of coordinating different solar cycles is there either way and unavoidable. So why not use the simpler system?

Meet me here tomorrow at 01:00

Yes, semantic drift in these terms would be unavoidable, but I still see the long-term benefits to clarity outweighing the short-term costs in it.

We already have that for technology to use - the unix timestamp.

A unix timestamp is an offset to a UTC date, not a timezone. But fair enough, there is UTC. It’s not used by default however, except by scientists and programmers maybe.

Maybe I’m missing something. What do you think the benefits would be?

Removing ambiguity from casual language. Currently when you state a time you are almost always implying your local timezone applies, which might be unknown information to the recipient, especially with written sources like these comments here. With everybody using the same timezone instead you would always make an unambiguous statement about the specific time by default.

What would happen on people that live in UTC+12:00 ? When your friend say “lets meet on Tuesday”, which Tuesday it is (because the day changes at noon)?

Given how +12 is at the front of the “date wave” currently they would probably take it to mean the Monday/Tuesday noon.

People will resist such majorly inconvenience changes unless the benefit of switching is clear for them. Forcing unpopular changes will guarantee people using unofficial timezone which cause even more confusion down the line.

Yeah fair. To me the benefit is clear, there is no good rhyme or reason to timezones as a totality, we should come up with a better system. A straightforward approach like using UTC offsets seems best.

They just gave an example though of people who made up their own timezone because the official one was bad.

Yeah, and in reply I argued that they did this out of not wanting to change their habit of associating 12 o’clock with noon. Which is in my opinion an understandable impulse but not a good reason to preserve the status quo.

These systems exist for people

Yeah fair, I’m aware I’m toeing unpopular opinion territory here.

and if no one other than programmers wants to do the internal calculus of “The sun is setting and they’re a quarter of the earths rotation Eastward, so that means they’re probably in bed” every time you want to call someone, then we shouldn’t make the standard that way.

But the standard is like that right now, worse even with DST and other complexities.

Right now you just look up the timezone in their profile and send it at 9:00, but without timezones, you need a “database of regional conventions for coordinating business hours”, which is just a worse way of having timezones.

Well no you need an offset. Like the user has set +8:30 as their offset, so send the notification at 00:30 UTC. That’s not worse than having timezones, that’s having timezones but simpler.

Timezones exist because they have a purpose.

Yeah, and some of those purposes are bonkers.

It’s like abolishing everything except latin1 because Unicode is a pain.

More like getting everyone to use Unicode, but whatever. Like I said I see why it would be unpopular to the point of being unenforceable, but that doesn’t mean an unambiguous way of communicating time as the default would be entirely undesirable.

Well the essay has a lot to discuss, part of which is already (or will be) addressed up and down thread, so towards your TL;DR:

Yes of course, I’m not suggesting to disrupt circadian rhythms. And yes, lookup tables for solar days will always be required, but I would argue this is an inherent complexity to how we measure time in relation to our behavioural patterns and environment. However doing that by using variously large timezones that do not quite match solar days at their edges anyway, with a lot of them changing their offsets by an hour for half the year, and some of them using half-hour offsets throughout the year, that is complexity added for administrative reasons which are partly obsolete and largely irrelevant to the question off what would benefit humanity as a whole the most.

If everybody were to use one single timezone you would memorise your relative offset to noon/midnight pretty fast. Like it’s one number to remember, e.g. where you are 4:40am is noon, 4:40pm is midnight, your offset is -7:20. Having those times be (roughly) 12 (for half the year) is just tradition and something we have every child learn. We could teach them about solar offsets just as well. It’s not even really more complex, arguably much less so since you remove the need to confuse them with the chaos that global timezones have grown to be historically.

Oh don’t get me wrong, I see how it makes sense. I’m just saying that 1) it is arbitrary nonetheless and 2) it doesn’t outweigh the benefits that could be gained by using a single global timezone. Incidence angle of solar radiation is hardly something most people need or even want to track beyond a certain degree (dawn, noon, dusk, midnight), and the times that would coincide with at your latitude and longitude can be easily learned.

people has this urge to associate 12pm to noon and 12am to midnight

Yeah but that is exactly what I mean with habitual. It’s a learned association of questionable utility. It can be unlearned and replaced with 0400 is noon or 1600 is noon based on your longitude just as well. Dawn and dusk are dependent on latitude and have to be learned for anything not smack-dab on the equator anyway.

I can see why that would be inconvenient to people, but I would maintain that is only so due to them clinging to a habit.

The fact that you give a preference to change something here which you give as an example for something that shouldn’t be changed because it would be problematic is deeply ironic to me.

Also, again, I don’t really see the problem with changing the date in the middle of the day. It’s virtually the same as changing it at 00:00 or 04:00, you change the date once every 24 hours. Right now you have a situation where one persons 3rd of the month could be another persons 2nd or 4th, depending on where on the globe they are. That’s not really ideal either, especially for that call scheduling example by the GP.

Cool, so sunrise is at 8 PM now.

And the problem with that is… ?

Or maybe there’s just no consistent relationship between what a clock on the East and West coast of America say, and a call can’t be scheduled between them.

If you get rid of timezones they all say the same time, no? If you want to schedule a call you just say the time and save the timzone offset fiddling.

The real problem with time and date is that it has to fit social and natural systems as well as actual passage of time.

Can you give any more concrete examples? None come to mind beyond habit, which is not an immutable thing.

pandoc.org is probably what you are looking for, but you might have to create a custom reader/writer or find one on the internet.

Absolutely, what we have on the Discord in the way of documentation is a straight forward install guide with one screenshot and a download link (of the GitHub release) and a FAQ channel, which is basically just links to the GitHub for a good part of the answers. We also automatically mirror our changelog there. But that’s it, and it’s all on GitHub as well.

What gets sadly lost on GitHub sometimes is “emerging events” like a new release of ours or the game we mod breaking something, where we will get yelled at on the Discord immediately and might have a hotfix release out before anybody even managed to create a proper GitHub issue.

Edit: Oh and temporary workarounds. If we figured something out on the Discord it doesn’t get posted to Github necessarily even if there is already an issue. Hence why I’m looking into having a bot for that instead of literally having to copy and paste a message.

I hate how devs use Discord for documentation. All the info on there is fleeting.

Guilty as charged, but in our defence we mirror most of the info from/to GitHub best we can. Also you can make the information somewhat less fleeting by pinning comments to a channel, using forum channels, or creating channels where users only have read access. Of course this doesn’t prevent the data from going away if Discord does, but to be fair the same can be said about almost all other services as well. GitHub servers get ransomwared and they don’t pay? Yeah your changes until their last uncorrupted backup are gone now unless you had backups of your own.

The reason why we use Discord in the first place though is network effect. The amount of reports and questions we get on Discord is simply no comparison to GitHub. It’s more simply because more users already have Discord than do GitHub leading to a lesser barrier of entry (account creation/program installation), especially for gaming related projects like ours. Of course this creates some added bureaucracy for keeping track of important reports from Discord. It’s kind of manageable to do manually, but I have been looking into ways of having a bot transfer messages/threads to GitHub by simply replying with an !issue 4321 command or something. Sadly I’m pretty sure we wouldn’t get half the reports we do on Matrix/IRC/XMPP/whatever, same diff if we were to switch from GitHub to GitLab basically.

Lastly, a server owner (or someone given the rights by them) can get an API key that enables them to dump the full server logs to disk. So if you really want your Discord server content to be indexed by search engines the possibility to just host a copy of your logs as a static website is technically there (we admittedly don’t do this yet, not sure if there are existing projects for this).

Know what data source isn’t fleeting? Forums.

Guess you never were a member of a forum with private sub-forums that went out of maintenance? That info is just as gone as our Discord logs if the company croaks tomorrow. And the public part is only available if it was mirrored to web.archive.org or something, which isn’t guaranteed either.

In summary, yes Discord isn’t the shit, it’s just shit, but the people are there. If the mountain won’t come to you, then you must go to the mountain. ¯\_(ツ)_/¯