> Forecasted month end costs
> There isn't enough historical data to forecast your spend
191–200 of 498 posts
> Forecasted month end costs
> There isn't enough historical data to forecast your spend
Earlier quoted context omitted.
I just dont get the “daily” weather records thing. Meteorologists talk about them constantly but theyre completely meaningless right? who cares what this particular day of the year highs were? its just noise! at least do it on a weekly resolution instead but even that seems so noisy itd be meaningless. sorry, this has nothing to do with you, just a pet peeve.
People like them because they happen more often. "This is the hottest February 29th on record!" but it's not the hottest February 28th or March 1st. Compare that to something more mathematically rigorous: "Today is warmer than 98.72% of days between February 25th and March 5th". Nobody's going to click that link.
but the idea seems like it's agreeing.
Yes, an amusing one: the Android app for the Berlin public transport, on the 29th, listed the results with the date of the previous day (28th). The funny thing is that the list is prefaced by a banner saying that this is a known bug, and the results actually refer to the 29th. Interesting way to workaround a bug :)
Date is relatively simple.
days_in_month(year, month) :
if(month==2) return days_in_feb(year)
//all other months have constant number of days, always.
days_in_feb(year,month) :
if(!(year % 400)) return 29;
if(!(year % 100)) return 28;
if(!(year % 4)) return 29;
return 28;
And you are done for all Gregorian years.Yes, I have a bot that posts daily San Francisco weather records to Mastodon. It did not post as scheduled today. This is because I am looking at all the high temperatures, low temperatures, and precipitation on today's date from 1875 (about as far back as there are digitized weather records I can work with) to the present. Since there was no such date as February 29, 1875 it is throwing an error.
I just dont get the “daily” weather records thing. Meteorologists talk about them constantly but theyre completely meaningless right? who cares what this particular day of the year highs were? its just noise! at least do it on a weekly resolution instead but even that seems so noisy itd be meaningless. sorry, this has nothing to do with you, just a pet peeve.
Though you're correct in that year-over-year weather changes and daily maxima lack the significance of long-term climate trends.
Earlier quoted context omitted.
Previously your unit test was broken one day every four ish years. Now it's broken every day :)
A unit test shouldn’t even be depending on the current date in the first place
Instead of doing
def do_something_with_date():
now = datetime.now()
return now - timedelta(days=2)
you should do def do_something_with_date(now):
return now - timedelta(days=2)
and explicitly pass in edge-case dates into the `now` param in your unit tests.Alternatively, if you're using Python, use the freezegun library to fix the current time in tests: https://github.com/spulec/freezegun
Heard from a friend in China: the age calculation portion of the app to schedule a marriage certificate had a bug where they subtracted 22 (legal minimum age) from the year, which resulted in 2002-02-29 which doesn't exist. The app intends to compare this against the user's birth date. The error handling code assumes all errors are from the comparison. The app then rejected all marriage certificate appointments by co…
so … many bullets were dodged today
Tell us about your last marriage?, lol
One thing I have learned from HN is that datetime issues are hard, prolific, programming language agnostic, and not to trust myself to get the logic right. (The same applies to floats.)
just like you don't roll your own crypto, you don't roll your own date libraries.
Earlier quoted context omitted.
It's not that python doesn't have a clean way to subtract a year, it's that "subtract a year" is imprecise. There's a clean way to subtract 365 days, and there's a clean way to set the year one year earlier. But if you're doing the second thing, is python supposed to silently change to March 1 when you change the year from a leap day? There's no way around handling edge cases.
This has been a factor in contract law for longer than computers have existed. "Subtract a year" or "Add a year" aren't really imprecise, it's just that there are two ways you can interpret it: 365 days, or 12 months. When adding, you get the same result: end of February, the 28th. Subtracting, you get one of March 1st for 365 days and February 28th for 12 months. Most jurisdictions use the 12 month standard, fwiw. I…
I just checked and realized I have zero annual Stripe renewals that have come through so far today. Not a big surprise, since most of our customers are on monthly subscriptions. I have wondered about how Stripe handles months with differing numbers of days (for monthly subs), and leap years (for annual subs). Do they accelerate renewals in short months, so that February 28 has all the renewals that normally happen on…
> Do they accelerate renewals in short months, Yes. They bill on the last day of the month if your anchor date is past that. In fact most billing systems do, which is why Feb 28th is the best day to load test billing systems. Because you'll get four days worth of renewals on one day. Interesting that you don't have renewals today, I wonder if they did them yesterday and have a bug?