Friends Don't Let Friends Look Dead On The Internet

Jess Lee on January 02, 2019

I love that we received six PRs to update all instances of the year 2018 --> 2019! What a fun contribution.

While thinking about this, I came across: I can't recall if there's a reason we've hardcoded the year.

That is all πŸ™ƒ

markdown guide

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. πŸ˜‚


I'm going to get a head start on next year and open a PR changing it to 2020 ;)


Better change it to "The Current Year" as everyone minus the cavemen know what year it is ;)


There is a reason not to automatically render the Copyright year to the current, because that is when the copyright is supposed to take effect. By always updating the copyright to the current year, you are basically saying that copyright starts this year, even though that may not always be true. I am not a lawyer, so I cannot give you the specifics of the law, but copyright is given by action, meaning as soon as you say/write something, you have copyright over it. You can probably automate it so that it updates when you publish new content, but updating it when there is no new copyrightable content is not good. You will have to talk to a lawyer, but usually automating legalese is not a good idea.


Disclaimer: I'm not a lawyer.

Exactly, I can't recall what I read on copyrights in that regards but from what I remember it's important that it stays related to the publish date of the webpage.
Not quite sure about content updates on the webpage itself, but I guess it would also be a case allowing a copyright year update.


I wonder how many people actually know what are the origins of this "standard" of displaying current year in the footer.


Well, I have no clue myself. I was hoping someone knowing more would shed some light on it.

Copyright notice used to contain the year in order to mark the time of publication of a resource, back in the darken days of internet. It also helped identifying the latest time for the rights to protect it. As far as I know it even was somehow defined in the copyright law, at least in the US.

Today though, when majority of websites are dynamic or user-generated, I find it difficult to justify this thoughtless chase to keep the footer's year up-to-date. :)


Different situation, but does anyone else get angry when they see that dates for things like "Top 10 [product name] in [year]", but the year is autoupdated?


ughhhh, I mean the title is already bad enough, but to stoop to that level... that's just gross.


Lol thanks Jess! This made me realize I had hard-coded my footer date πŸ˜…

code of conduct - report abuse