Marching Events: What does iCalendar have to do with ray marching?
pwy.io
pwy.io
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.
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.
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.
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
Hah - fair enough!
I'm joking of course but there's a grain of truth. The meme of a lost 10mm socket is just as true in America and most tool sets come with both imperial and metric sizes. It's really annoying to have to double up. But wouldn't be America if we didn't have unnecessary complexity, right? Can't be a real programmer™ without facing that on a daily basis
Please don't use dd-mm-yyyy. It's better to use different separators to clarify the date format. The three common formats are yyyy-mm-dd, dd.mm.yyyy and mm/dd/yyyy.
In the U.K. when handwriting I think dd/mm/yyyy is much more common than dd.mm.yyyy
I wasn't listing a date format, but a date order; the dashes were not meant to be separators. That said, I tend to use year-month-day, in RFC-3339 format. Although I honestly don't lose sleep about it.
> It's better to use different separators to clarify the date format. The three common formats are yyyy-mm-dd, dd.mm.yyyy and mm/dd/yyyy.
As an American, I most commonly see day-month-year written as "April 17th, 2025" or "4/17/2025". I'm sure "4.17.2025" exists, but e.g. it is not what a locale-aware date formatter will output for U.S. locale.
Here's my hot take: One should generally either use locale-specific date formatting, or use RFC 3339 or ISO 8601. They both have a time and a place where they are more appropriate. Sometimes it's just simply going to be more correct and less confusing to use a locale-specific date format, especially if you have to deal with passing dates between different entities. (As an example, if I were filing legal documents, I would most assuredly use the standard in a given locale for dates. Maybe a long, unambiguous form just to be safe, if it happens to be applicable.) In any case, using another option that isn't either of these seems counter-productive to me.
I think it's weird how people get overly attached to issues like these. It is a shame that date formats can be ambiguous, occasionally causing preventable problems, but we'll survive. Stuff like this doesn't get fixed over night.
2. it's, ironic?, because the post dates are in dd-mm-yyyy
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.
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.
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!
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!
And Feldera/DBSP is absolute magic - definitely something I want to dig deeper into!
Ugh. I did just this sort of "dynamic pricing" shenanigans for a travel company years ago. It made me feel dirty.
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.
Contrast this with opening the same .ics file from an email attachment or viewing it online, which presents an "Add All" button.
Not that I ever get a .ics file from anywhere except my emails, but it would be nice to be able to actually use them if I have them.
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.
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 ???
You're right, thanks - fixed! Small typos like those are the hill I'll die on.
> But I would expect curr.last_of_month().tomorrow().unwrap(), to return 2018-03-01 ???
This case actually matches the `Ordering::Less` branch (14 < 31), so it hits this arm:
Ordering::Less => curr + Span::new().days(day - curr.day()),
2018-02-14 + (31 - 14) = 2018-03-03
I've rephrased this section in the article to show the calculation more clearly now.
f(packet, time, ...) = { reject, allow }
But this got me thinking about cases where policy _modifies_ the packet, like:
f(packet, time, ...) = ({ reject, allow }, new-packet)