Pretty disingenuous to emphasize "building a culture of transparency" while simultaneously not disclosing how heavily AI was [very evidently] used in writing this post.
I’d say around ~40% me, the ideating, editing, citations, and images are all mine; rest Opus 4 :)
I typically try to also include the original Claude chat’s link in the post but it seems like Claude doesn’t allow sharing chats with deep research used in them.
Labour doesn't make money until the labour is already provided, so how much money labour can produce is an unknown until hindsight is available. An established company with a stable business can make some pretty reasonable forecasts, but when it comes to startups and other new business ventures one is ultimately straight up guessing.
Demand being a function of how much investment money is available is going to be closer to reality, although that is not the whole story either.
To have a better understanding of what operations you are trying to do. I can't answer your question specifically because it depends a lot on use case and what date/time standards you want to use.
To expand on this a little, there are operations that have slightly ambiguous meanings/can end up with different answers depending on your assumptions.
e.g. If today is the 30th of January 2024. What is the date in 1 months time?
Should it be the 29th of February? (as the 30th doesn't exist). The 28th? (the penultimate day of the month, like the 30th of Jan). The 1st of March (a 'standard' month should be considered 30 days, so 30 days from now).
To be honest, use a library where someone else figured out the ambiguities and accounted for the edge cases. Good starting point: https://moment.github.io/luxon/#/math
Date-fns is fine for simpler use cases but Luxon is a lot more complete, especially where it comes to time zones.
This is not the kind of thing you just want to blindly hack your way through without a really thorough understanding of how different cultures/locales/governments handle dates and times.
If you have to do math across daylight savings time boundaries that change over time (because governments and regulations change), converted to two or more time zones (which again have their own separate DST rules), and possibly span some 30 or 45 minute time zones (they exist!) this will quickly get out of hand and unreadable. Not just unreadable, but incredibly difficult to reason about.
It gets even worse when the backend stores only the offset (as in the ISO time, like T23:00:00+08:00) because then you lose the original time zone and can't be sure whether it came from a DST zone or another country in the same zone (but only during part of the year).
When you cross DST switchovers, for example, you may magically gain or lose an hour. A naive milliseconds calculation will miss that. It gets worse because DST in a country isn't a static thing either, but will change with the laws over time. So over decades, you need to have several lookup tables.
And people are ambiguous. Is January 31 plus 1 month the end of February or the beginning of March? What about during a leap year?
And a "day" isn't necessarily 24 hours (because of DST, again). Humans doing day math across those boundaries will just ignore (or really, never think about) the missing or gained hours, but computers have to explicitly account for it.
Then once you throw in different time zones it gets even crazier, especially for the half hour and 45 minute zones.
It's okay to store datetimes in epoch milliseconds (ideally with a separate field for the time zone, not just offset, which holds less information). But you can't easily/correctly do math on that without more specific instructions and cultural/locale adjustments.
Someone had success using GPT-3 to classify episodes of a podcast[1]. I imagine if you fed the HTML from the crawler into an LLM, it could come up with a usable classification for it.
Had to do a Calculus course in uni despite not having taken any calc or pre-calc in high school. "Precalculus Mathematics in a Nutshell" and "Calculus Made Easy" were complete lifesavers.
Yeah container queries are what I'm most excited about looking at this list. I was pretty bummed out to see they're only supported on 63.75% of browsers, and notably missing on most mobile browsers, where they'd be most useful.
