msandin

My Bevy game (released on Steam) has ~37k lines of Rust, and is stuck on Bevy 0.15 for this reason. It's not been a big problem for me though, because Iv'e ran into very few Bevy bugs (none that forced an update) and I was deep enough into production that I had already solved all problems with the 0.15 feature set. Overall, it's been a pleasure, and at the time of the 0.14->0.15 upgrade my codebase was small enough that it was done in an hour or so.

While I don't disagree with the toy/game distinction I also think the lines are blurry enough that I'd place the former as a subset of the latter.

They are sold in the same places, run on the same hardware, use the same conventions and interactions, fill the same place in our lives, and are discussed in the same places. A lot of "proper" games also have digital toy modes: Minecraft and various sim games come to mind, but there are many. Insisting that they are completely distinct things seems mostly silly TBH. Almost everyone in the world would recognize Tiny Glade and its ilk as a kind of "computer/video game".

Having seen this in person my favorite aspect is the sound it makes, absolutely mesmerizing.

I mean, obviously possible but I suspect that the clumsy translation adds a lot of obtuseness to it. In Swedish it looks straightforward enough that you only need to squint just for a moment when you see "överkast" and "Indira" together and then you get that familiar feeling of "How could I ever miss that?".

They're missing an explanation for one of the more famous but subtle IKEA naming puns.

"Indira" is at this page says an Indian name and also the name of an India-inspired IKEA bedspread. But bedspred in Swedish would be "överkast" which would translate directly as "over throw" but could also be read as "over caste". From a Swedish PoV the Indian caste system looks like a social ranking system and to Swedes one of the most famous (and thus presumably socially high ranking) Indians "just happened" to be named... Indira.

Of course we knew who did what and when, that was not the problem and I never said it was. But the start date+time they entered for recurring series was converted to UTC on the client before it was sent to the server. So when it was decided that what they really wanted wasn't to run it "every 24 hours after the start date+time" but to run it on the exact time they entered every day, starting on the day they entered, the information about the exact time they had entered was gone.", all we had was that time converted to UTC. This meant we could not deduce the original time zone in which it was entered and thus could not deduce which DST schedule it should follow to keep it running at the same time every day.

The answer to the question "when did some work happen" is an instant and I specifically said that instants should be stored in UTC. I'm talking about storing recurrent schedules, i.e. information about when an (potentially infinite) series of future events should take place. And that information is not a series of instants and can't be stored as UTC timestamps because it's potentially infinite, subject to future reconfiguration, subject to future timezone offset changes, and must be preserved in a format that allows it to be viewed and edited (Thursdays odd weeks at 10:00 is not easy to glean from a series of pre-calculated numbers).

Please make the distinction that _instants in time_ should be stored in the UTC but time specifications for scheduling purposes (10:30, mondays 14:50, 2017-05-17T13:40) are not instants in time, they are specification of time to be interpreted in a specific time zone and should be stored as such.

In a very real example there was once a product which let you schedule events by specifying a start date and a recurrence interval, say "daily". The software converted the start time to UTC in the zone of the schedule creator and stored that. But the conversion was done at the creation time which means it was done with a particular offset (say -5 hours) and when the relationship between the creators time zone and UTC changed as a result of DST changes the schedule ended up one hour of from what the creator intended. And the information about which timezone the thing had originally been scheduled in was lost and could not be retrieved.

Indeed, but this is representative of a very real change in the relationship between your clocks. The only way to keep this non-surprising is to make the time zone the schedule runs in explicit to the user. If somebody in a different zone edits the schedule it has to remain in the original time zone unless they explicitly change it. You do all your scheduling calculations in the schedule time zone and then convert it to an instant in time, likely expressed as a UTC time, when you need to calculate how long your computer should wait until the next event.

(Date)Times stored in the schedule (start times, end times, trigger times, clock times) are not instants in UTC, they are time specification in a calendar system which can only be interpreted as specific instants in the context of a particular time zone. Which is stored explicitly and separately from the calendar date-times.

This crucial separation of a time specifications in a calendar system from instants in time is one thing which many date/time libraries get wrong and which Noda-/JodaTime gets right.

Unless you do recurrent scheduling. In that case it's important to understand that you schedule in a particular timezone. Both because the relationship between local time an UTC changes throughout the year with DST changes and because evaluating an expression like "Thursdays at 03:00" might evaluate differently if you first move the time to UTC (say 22:00) and then check if it's a Thursday (no, it's only Wednesday still, but in 24 hours it'll be time).

Not very it would seem given that "pipa" does not mean "pipe" in the sense TPB are using it but rather only in the sense of a "pipe for smoking". A pipe in the sense TPB use it would be "rör". But relating the combination "trash" and "pipe for smoking" to their line of reasoning seems at least a little harder/more far fetched.