Marching Events: What does iCalendar have to do with ray marching?

I've thought of this a lot!

Lots of hospitality booking and pricing engines, for instance, require materialization of complex rules: if suppliers have rules that say "if the checkin is on these 3 days of each week add a price multiplier, which stacks with the holiday pricing event that happens every year, but only if you're a certain number of days out from check-in" you need to be able to render this for arbitrary date ranges to provide pricing calendars.

And you can use simple iteration if you want to render for a single property - but what if you want to render a queried week's pricing across a massive corpus of units, where every millisecond of latency is a lost conversion opportunity? And where any supplier could change their rules at any time? And where length-of-stay and per-guest pricing might come into play, adding more dimensions that make full materialization hard to do?

(Google, for instance, has something akin to this problem, in how it integrates with hotel suppliers using https://developers.google.com/hotels/hotel-prices/dev-guide/... .)

You might even think, in this context: how can I represent the rules on a GPU or other system with limited working memory, and be able to render search results the way I'd render tiles?

Then things like the OP's post become vital considerations, and far from just simple analogies!

> yes, this blog is a proud user of the european date format - if you don't want to see yyyy-mm-dd's, please press alt-f4 and go back to boycotting bud light or something

Interesting to call this the "european date format", given that prior to ISO 8601 I'm pretty sure this date order was almost entirely used in East Asia and not Europe. To me day-month-year will always be the European date order.

Ubiquitous and, unfortunately, almost always implemented with some bugs.

Yep, I knew it as the Japanese format

1. where did you find that on the page?

2. it's, ironic?, because the post dates are in dd-mm-yyyy