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
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.
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.
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)