How to date languages

Question

Some challenges refer to the year a language was released. If a release is dated on 31 December or 1 January, it may depend on locale.

Should Github date be used as the official date (whatever locale the Github server is using)?

And if Github was not used to release the language, should it be the date where the company/organization was based at the time of release?

Or maybe the Zulu-time at the moment of release?

Maybe we should go by whatever date was written (or meta-data) in the release document itself?

Solution: don't make challenges that are dependent on the date a language was released (except for the specific timestamp the challenge was posted, although I personally don't even like that). I'm sure there are better ways to encourage answers in old languages if that's your goal. — Martin Ender, Mar 10 '16 at 17:49
@MartinBüttner Can you give an example of how to encourage answers in old languages in a better way? — Adám, Mar 10 '16 at 17:53
If you want to see answers in old languages on a challenge, put a bounty on it and give it to the best answer in a language created before 19XX. — Martin Ender, Mar 10 '16 at 17:56
@MartinBüttner "best"? Many things may be writable in Plankalkül. There needs to be some gradation... — Adám, Mar 10 '16 at 18:03
I mean "best" for the given winning criterion. Alternatively, give it to the oldest language (provided the solution is valid and attempts to compete). — Martin Ender, Mar 10 '16 at 18:05
@MartinBüttner Also, being that golfing languages have evolved over the years to express things shorter and shorter, I think a scoring that combines length and release gives and interesting balance. — Adám, Mar 10 '16 at 18:06
Step 1: ask them if they'd like to go to dinner/see a movie/get coffee with you. — Mego, Mar 13 '16 at 23:28
@Mego Nice one. I came here to make a similar joke, but I guess you beat me. Just make sure the language is old enough. — mbomb007, Mar 21 '16 at 18:40

Dennis · Accepted Answer · 2016-03-10 17:52:10Z

Use UTC

All SE time stamps do, so it makes sense to extend this to other aspects.

Using GitHub's time zone (UTC -3) seems arbitrary, since code can be hosted elsewhere.

Using the hosting platform's local time seems even more arbitrary, since not the moment but the place of publication could determine the date.