[HN Gopher] Marching Events: What does iCalendar have to do with...
___________________________________________________________________
Marching Events: What does iCalendar have to do with ray marching?
Author : Patryk27
Score : 63 points
Date : 2025-04-16 12:10 UTC (1 days ago)
(HTM) web link (pwy.io)
(TXT) w3m dump (pwy.io)
| btown wrote:
| 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!
| Patryk27 wrote:
| Curiously enough, I've used to work in hospitality!
| (https://pwy.io/posts/mimalloc-cigarette/ &
| https://pwy.io/posts/memory-for-nothing/)
|
| Our dataset wasn't so large as to warrant experimenting with
| GPUs - `cost(extraCpu) < cost(developerExperimentingWithGpus)`
| - but the CPU implementation got a lot of love; it was mostly
| engineering-based work, though ("how to load stuff from the
| disk effectively", "how to make it multi-threaded" etc.), not
| math-based work ("if we represented prices using
| $someFancyStructure, we could ...").
|
| I like when seemingly engineering-oriented problems turn out to
| be way more approachable once you apply / invent / adjust some
| math foundations, e.g. like with Feldera (https://sigmodrecord.
| org/publications/sigmodRecord/2403/pdfs...) - wouldn't figure
| something like this myself in a hundred years, I'd just
| probably apply maps on top of caches on top of whatever else I
| could pile until it works!
| btown wrote:
| A channel manager using Rust for the caching layer? That's
| actually kind of incredible. Might want to pick your brain
| someday :)
|
| And Feldera/DBSP is absolute magic - definitely something I
| want to dig deeper into!
| reaperducer wrote:
| _" 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._
|
| Ugh. I did just this sort of "dynamic pricing" shenanigans for
| a travel company years ago. It made me feel dirty.
| ctippett wrote:
| One of the few remaining ubiquitous open formats of the web.
| Unfortunately Apple still refuses to recognise *.ics files unless
| they're included as a Mail attachment.
| imp0cat wrote:
| Ubiquitous and, unfortunately, almost always implemented with
| some bugs.
| kridsdale1 wrote:
| What do you mean? You can open them in Finder or iOS Files app
| and a calendar import UI will be shown.
| ctippett wrote:
| Opening an .ics file on iOS from the Files app will show the
| events, but will _not_ allow you to import /add them to your
| calendar.
| reaperducer wrote:
| _Opening an .ics file on iOS from the Files app will show
| the events, but will not allow you to import /add them to
| your calendar._
|
| Not true. I just tried it on an iPhone 14 with iOS 18.4,
| and it works fine.
|
| You tap on the ics icon, and it opens up the details. Tap
| "Done" and the event lands in the calendar you specified.
| Telemakhos wrote:
| Apple's built-in Calendar program on macOS will import
| VEVENT entries just fine; most programs handle VEVENTs in
| an .ics file well.
|
| VTODO, on the other hand, is broken in many applications,
| and I've only gotten VTODO to work on Mac once in my life--
| and I don't remember how. Outlook flat-out ignores VTODO.
|
| If every calendar app supported VEVENT and VTODO well, my
| life would be much, much simpler. I'm required to use some
| cloud software that tracks events and tasks, and I'd love
| to sync it to my phone and have those events and tasks show
| up as events and tasks. But, because very few calendars
| import VEVENT correctly (or at all), my cloud software
| exports both events and tasks as VEVENTs--events for the
| correct duration, and tasks as a five-minute event on the
| due date. This is a stupid kludge to get around the usual
| bad support of VEVENT, and it's one of the things that
| raises my blood pressure the most.
| emchammer wrote:
| Apple Intelligence now scans the entire email and sends me its
| best guess of the event date, time and location, which causes
| me to second-guess it and contact the organizer again anyway.
| jchw wrote:
| > 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.
| Patryk27 wrote:
| Ah, you're right - I wanted to include a dunk, but forgot to
| actually fact-check it! -- gotta figure out something better.
| DiggyJohnson wrote:
| Why would you want to do that? I don't think Europeans
| realize how familiar technical and engineering minded
| Americans are with metric. It's just so overplayed.
|
| GP is right my default reaction as a MM/DD/YYYY dumb American
| was that you didn't make sense because that is the
| internationally standardized unambiguous format and what we
| all use for dates where sorting or i18n matters. Sorry for
| rant you probably don't deserve it but for real that is the
| lamest joke imaginable and your content is good enough that
| it doesn't need "dunks"
|
| Edit: get dunked on
| Philpax wrote:
| Seems like the dig dug into you to make you respond like
| this.
| LtdJorge wrote:
| Yep, I knew it as the Japanese format
| benjadolele wrote:
| Not just Japanese, but I believe most East Asian countries as
| well.
|
| Interestingly, not only with dates, but they order things
| from the "biggest" to the "smallest"
|
| Like Year-month-day for dates.
|
| Family name - personal names for names.
|
| And for address, they start with country, city, street name,
| then house number. Opposite of what is more common in western
| countries. I actually find it more useful as very often I
| remember which street my friends live in but not the house
| number, and I can type it in and expect google maps to give
| me the result based on my search history. Not so useful with
| house numbers if you can't remember them.
| reaperducer wrote:
| _And for address, they start with country, city, street
| name, then house number._
|
| A generalization that does not apply in places like Tokyo,
| where many houses are numbered by their age, and street
| names are not used at all.
| perching_aix wrote:
| Also applies to Hungarian and Lithuanian, which are in
| Europe. Still, I agree, weird to characterize it as
| European.
| hk1337 wrote:
| 1. where did you find that on the page?
|
| 2. it's, ironic?, because the post dates are in dd-mm-yyyy
| Patryk27 wrote:
| I've redacted that part (https://github.com/Patryk27/website/
| commit/818c27967d7e6332c...), since it doesn't quite make
| sense if you think about it for longer than a couple seconds;
| it's 23:02 for me at the moment, maybe the night will bring
| me a new joke!
| reaperducer wrote:
| _To me day-month-year will always be the European date order._
|
| If you're a fan of digging through old letters in British
| antiques stores, you'll find that the "American" date format
| that people on the internet like to complain about was
| inherited from Britain (along with the imperial measurement
| system).
|
| It was only after the American Revolutionary War that Britain
| switched to putting the day before the month. Probably during
| one of its many Francophilia phases that seem to come and go
| throughout its history.
| xenadu02 wrote:
| Fun fact: you can be the change you want to see!
|
| I fill out all paper forms and typed dates as yyyy-MM-dd
| wherever possible. No one has ever been confused by it. Some
| have even copied it.
|
| I also give units in metric sometimes and set some of my
| thermometers to C to help build my intuition for what
| different C temps feel like.
|
| On the other hand I'm setting up a hobby machine shop at home
| and trying to use metric or a metric lathe would involve too
| much swimming upstream so alas - it is all imperial stuff.
| rgovostes wrote:
| I was really hoping this was going to be a demonstration that the
| recurring event frequency field is Turing complete by
| implementing a ray tracer in it.
| Patryk27 wrote:
| Gotta leave something for others to discover!
| UltraSane wrote:
| Would this work for network ACLs?
| toast0 wrote:
| First, thanks for this mental model; I've got a project with
| iCals where I haven't been happy with the logic, and maybe I can
| clean it up with this! But I don't think the text matches the
| examples...
|
| This seems like an error?
|
| > (day-of-month 12 2018-01-14) = 2018-02-14 > // 2018-01-12 is
| the closest 12th day of month starting from 2018-01-14 (-2d), >
| // but that corresponds to a negative span, so we jump to the
| next month
|
| Shouldn't the nearest 12th day of the month after the 14th of
| January be 2018-02-12 ?
|
| > Rule::DayOfMonth(31) > .next(date("2018-02-14"))
|
| > ... will say 2018-03-03 - which is legal, because the actual
| next occurrence happens on 2018-03-31, for which 2018-03-03 is a
| valid underapproximation.
|
| But I would expect curr.last_of_month().tomorrow().unwrap(), to
| return 2018-03-01 ???
___________________________________________________________________
(page generated 2025-04-17 23:00 UTC)