Weekly edition Kernel Security Distributions Contact Us Search Archives Calendar Subscribe Write for LWN LWN.net FAQ Sponsors

Large version numbers

Large version numbers

Posted Nov 9, 2011 8:21 UTC (Wed) by ekj (subscriber, #1524)
In reply to: Large version numbers by codewiz
Parent article: Firefox 8 released

Precisely. A year is *actually* 365.24 days (give or take). And a day is *actually* as long as it is. And a moon-cycle is *actually* as long as it is, allthough that has little practical significance. (and doesn't match the "month" anyway)

But sure, we could use year day.fraction and do away with months, weeks, hours, minutes and seconds.

2011 150.5 would be mid-day on the 150th day of year 2011.

Large version numbers

Posted Nov 9, 2011 12:47 UTC (Wed) by robbe (subscriber, #16131) [Link]

Multi-part dates (or version numbers, to give some semblance of being on-topic) seem to be easier to parse than unstructured ones.

Quick: if I invite you to an outdoors event on 2012 day 222, will you need to bring your jacket? I guess we could start to remember key day numbers (e.g. "frost recedes around 74", "324 is our anniversary"), but I think we more easily remember day-month combinations than three-digit numbers.

The days-since-the-epoch scheme is insane.

Large version numbers

Posted Nov 9, 2011 12:59 UTC (Wed) by ekj (subscriber, #1524) [Link]

I dunno about that. you can skip the last digit in the year if you care only about season, you're thus left with 36 10-day periods, I guess that granularity is a little high, but I don't think it's a *lot* harder.

Do you need a jacket for an event at 22/36 of a year isn't much harder than Do you need a jacket for an event at 8/12 of a year which is the current system.

Multi-part version-number can confuse too; I've seen several people be confused about what is better: 2.27 and 2.3 if you read them as decimals, you'll end up thinking that 2.3 is the higher number thus the newest version.