Even though it’s completely irrational, my thought process for having it be hardcoded is because if we only have to change it once a year, why re-compute it over and over again all year?
It’s irrational because it’s one of thousands of such computations and we don’t even consider these kinds of nano-optimizations elsewhere.
So that was why things are. I think it’s kind of stupid, but that’s why.
Just want to loop @rhymes
in on your response 😄
I'd definitely see the hardcoded date as legacy code, if not now, someday. May as well merge the Time.current.year PR.
Is the compute time of recalculating it over and over again more or less burdensome than receiving multiple PRs and spending the time to address each of them – including closing five (or more next year!) of them?
If you answer that I think you'll have a good reason to either merge or close the Time.current.year PR 🤗
Abhaha I agree with you, let's keep it hard-coded or put it dynamic but in a partial, cached until 2019 ends 🤔
I actually quite enjoy this odd throwback ritual, but acknowledging that in pure software/productivity terms it should be computed. Merged a PR that does that.
Since we're eyeing a future where people can stand up their own version of our open source platform community, hardcoded dates will eventually be bad legacy code.
Since we're hoping that future happens at some point in 2019, makes sense to go computed now. 😂
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.