> 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.
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.
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”
Conspiracy theory: US will never switch to metric because then you'd sell half as many tools.
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
> To me day-month-year will always be the European date order.
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.
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.
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!
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.
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?
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!
"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.
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.
What can I say, other than we have very different experiences. Opening an .ics file from the Files app indeed shows its details, but selecting "Done" does nothing but dismiss its contents and adds nothing to the calendar.
Contrast this with opening the same .ics file from an email attachment or viewing it online, which presents an "Add All" button.
I thought, surely this can’t be right - but can confirm that this is the behaviour I see as well, opening a .ics file in Files lets you inspect the event but doesn’t seem to give you any way of importing it into a calendar (even from the share sheet). Maybe you could email the file to yourself but that seems like a pretty roundabout way of doing it.
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.
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.
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.
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 ?
> ... 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 ???
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.
In that case evaluating the function once is enough to know whether the packet should be let through or not, there's no way to sort of "differentiate" this function, no way to step through it.
But this got me thinking about cases where policy _modifies_ the packet, like:
f(packet, time, ...) = ({ reject, allow }, new-packet)
In this case you'd be looking for a fixed-point, evaluating this function until new-packet = packet (or you exhaust some time and give up). Not sure on the potential utility, though - just a random thought.
Makes sense. Advanced ACL analyzers translate them into first order logic and then use something like Z3 to find the packets that satisfy them but they rarely support the time based ACLs. But those are not used much in practice.
> 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.
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.
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.
I've had forms rejected for using ISO-8601 dates in the US. I still do it by default and only amend things if asked to.
I like to think of them as Big Endian (yyyy-mm-dd), Little Endian (dd-mm-yyyy), and Middle Endian (mm-dd-yyyy).
Actually a really smart way to teach endian. I no longer need to do that but it would have been useful lol
Ah, you're right - I wanted to include a dunk, but forgot to actually fact-check it! -- gotta figure out something better.
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
> that is the lamest joke imaginable and your content is good enough that it doesn’t need “dunks”
Hah - fair enough!
Conspiracy theory: US will never switch to metric because then you'd sell half as many tools.
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
better mousetraps solutions exist: https://metrinch.com/metrinch_en/
Seems like the dig dug into you to make you respond like this.
[dead]
> To me day-month-year will always be the European date order.
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.
Much of that depends on country for usage.
In the U.K. when handwriting I think dd/mm/yyyy is much more common than dd.mm.yyyy
> Please don't use 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.
What about \d{2} \w+ \d{2,4}
1. where did you find that on the page?
2. it's, ironic?, because the post dates are in dd-mm-yyyy
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!
Yep, I knew it as the Japanese format
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.
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.
Also applies to Hungarian and Lithuanian, which are in Europe. Still, I agree, weird to characterize it as European.
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!
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!
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!
"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.
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.
What do you mean? You can open them in Finder or iOS Files app and a calendar import UI will be shown.
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.
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.
What can I say, other than we have very different experiences. Opening an .ics file from the Files app indeed shows its details, but selecting "Done" does nothing but dismiss its contents and adds nothing to the calendar.
Contrast this with opening the same .ics file from an email attachment or viewing it online, which presents an "Add All" button.
I thought, surely this can’t be right - but can confirm that this is the behaviour I see as well, opening a .ics file in Files lets you inspect the event but doesn’t seem to give you any way of importing it into a calendar (even from the share sheet). Maybe you could email the file to yourself but that seems like a pretty roundabout way of doing it.
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.
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.
We made the deliberate choice on MacOS to remove VTODO from iCal when it split out to the Reminders App and started to go beyond the open protocol.
The irony being that iCalendar would be exactly what it'd be called if Apple had invented it.
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.
Ubiquitous and, unfortunately, almost always implemented with some bugs.
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 ???
> Shouldn't the nearest 12th day of the month after the 14th of January be 2018-02-12 ?
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:
... yielding this calculation: Since the actual next occurrence is on 2018-03-31, 2018-03-03 is a valid guess (just a suboptimal one).I've rephrased this section in the article to show the calculation more clearly now.
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.
Gotta leave something for others to discover!
That page is the perfect density for mobile. I also liked the colors and the contrast. Well-written stuff to boot!
can't help but wonder if I'd like this syntax for system timers or cron...
Would this work for network ACLs?
ACLs are more like a binary function, right?
In that case evaluating the function once is enough to know whether the packet should be let through or not, there's no way to sort of "differentiate" this function, no way to step through it.But this got me thinking about cases where policy _modifies_ the packet, like:
In this case you'd be looking for a fixed-point, evaluating this function until new-packet = packet (or you exhaust some time and give up). Not sure on the potential utility, though - just a random thought.Makes sense. Advanced ACL analyzers translate them into first order logic and then use something like Z3 to find the packets that satisfy them but they rarely support the time based ACLs. But those are not used much in practice.