The Math of Leap Days 225
The Bad Astronomer writes "We have leap days every four years because the Earth's day and year don't divide evenly. But there's more to it than that... a lot more. A year isn't exactly 365.25 days long, and that leads to needing more complicated math and rules for when we do and don't have a leap year. If you've ever wanted to see that math laid out, now's your chance, and it only comes along every four years. Except every hundred years. Except every four hundred years."
Duh. (Score:4, Funny)
Its not that hard (Score:5, Interesting)
On climagic I laid it out in less than 140 characters. [twitter.com]
Re: (Score:2, Funny)
ARRGH, a twitter feed I acutally want to follow.
Length of year, day, etc. (Score:3)
Re: (Score:3)
Re: (Score:3)
Due to tidal forces slowing the Earth's rotation, in the year 30,000, the day will be about half a second longer resulting in the year being only 365.2401 days long, so we will need to adjust our algorithms a lot sooner than that
Re: (Score:3)
If the days would become shorter, that means we'd be able to drop the %400 rule somewhere between now and Y30K, but since a day is actually slightly longer than what our current algorithm accounts for, the two might just cancel eachother out to let the algorithm last well beyond 30K. I'm too lazy to try and do the math to verify.
Re: (Score:3)
Re:Duh. (Score:5, Informative)
No, the REAL nightmare for programmers is daylight savings time. Especially in the spring, when local times jump back and repeat. Ugh.
Re:Duh. (Score:5, Insightful)
No, the REAL nightmare for programmers is daylight savings time. Especially in the spring, when local times jump back and repeat. Ugh.
That's why you should save the time in UTC format, and then let the OS help you translate that into a display time.
Re: (Score:2)
It is still a nightmare though. Just for a different programmer and not you. You have to approach the problem by reading the time first, then deciding on how to store it. That means you need to rely on that system, and some may be better than others. I would think most systems are relying on Linux and the zoneinfo files to get the time correctly.
So some programmer still needs to deal with the fallout from the fucktarded Congress Critters that decided to tank millions of devices worldwide that depended o
Re: (Score:2)
Time should be like internationalization. Everything internally is UTC or at last based on something other than local time; and strings are all multibyte. Everything is passed around this way untouched, uninterpreted. The only time you deal with locale settings is just before outputting the values and just after inputting them.
And yet people keep getting this wrong... You end up with a customer whose facilities straddle a time zone boundary, or the server and client are in different time zones, and then
Re:Duh. (Score:5, Informative)
You mean universal? That just means a standard.
A UTC formatted time stamp always contains a time zone
No, it doesn't. It never contains one -- it always represents local solar time in Greenwich, London (without getting into detail only of interest to astronomers).
However, it's often stored with a timezone, or processed using one. For example, RFC 2822 date format, which is what you get with
$ date -R
Thu, 01 Mar 2012 10:29:22 +0000
I happen to be in London, so my timezone is +0000 right now.
$ TZ=:Asia/Tokyo date -R
Thu, 01 Mar 2012 19:31:12 +0900
$ TZ=:Europe/London date -R -d 'now + 80 days'
Sun, 20 May 2012 11:32:35 +0100 (+0100, for British Summer Time)
In these cases, what's being used is UTC and a location. The location (mine is set to Europe/London) is used to find the timezone offset for any particular date and time. This even takes into account historic (or known-future) changes:
$ date -R -d '1941/07/01 12:00 +0000'
Tue, 01 Jul 1941 14:00:00 +0200 (Britain used "Double Summer Time" during World War 2)
$ TZ=:Europe/Jersey date -R -d '1841/07/01 12:00'
Thu, 01 Jul 1841 12:00:00 -0001 (The island of Jersey, between England and France, didn't start using GMT until 1898)
Re: (Score:2)
Twice a year I get marketing people coming to me and asking what happens to the product that doesn't have a certain bug fix. And twice a year they write it down, and promise to get some QA to test it to be really sure.
Everything should be in UTC. Except that we have to integrate with products that insist on local time. Or bizarre time formats.
Re:Duh. (Score:5, Informative)
Here is one the UTC/DST problems in a nutshell, and why it's not as simple as you think:
Assumptions:
-Me and my user are in UTC +10
-DST puts us into UTC +11
-DST runs from 1 October until 1 April
I am writing a "family reminders" application for mobile phones. A user enters two reminders. BOTH reminders are activated for the user and his wife, reminding them to take some medication. One is for 10 March 2010 at 1130AM and the other is for 10 April 2010 at 1130AM.
How do I store these date? I am a SMART programmer, and I store them as 2012-03-10_0030 and 2012-04-10_0130.
I was clever. I looked at the user's timezone setting, projected into the dates they were setting to appropriately modify the UTC time depending on DST or not.
Two things happen:
1. The user's wife flies to the west coast on 9 march, 3 hours earlier. On 10 march, do we alarm her at 8:30, per UTC? Or do we look at her new current time zone vs when it really was set and alarm her at 11:30 local time?
2. The "making summer longer" act is passed, extending DST to 15 April. Do we alarm them at 11:30am, or at 12:30pm? Why?
The solution to both of these is to give the users a bunch of checkboxes they don't quite understand, or to make assumptions that might wind up incorrect. Either way there's no "win win".
Re:Duh. (Score:4, Interesting)
UTC includes leap seconds. TAI does not.
I think you're doing it wrong (Score:4, Informative)
You seem to have misunderstood the point the GP was making. If the computer internally stores the time as UTC then the stored time will always progress forward (UTC isn't affected by DST like GMT is), and behind the scenes it'll always be searchable. It's also about as future-proof as we can make it; if rules regarding leap years or calendaring in general change, you're screwed regardless of which system you're using. The DST translation should be done for display purposes only, based on the user's preferences for localization etc. Proper separation of content versus display logic should solve all of the problems you brought up. Those problems only become issues for people working with heterogeneous data sets (time stored differently in different data stores), in which case you'd expect to be writing translation routines anyways.
For years (Score:5, Funny)
and it only comes along every for years.
Wow! That really IS rare!
Re: (Score:3)
Re: (Score:2)
for(int years = 0; years LENTH_OF_UNIVERSE; i++) { /* article */ }
Re: (Score:3)
Slashdot's crap filter didn't help.
Re: (Score:2, Funny)
That must be the American spelling: there's no "u".
Re: (Score:2)
Re: (Score:3)
"The Bad Astronomer writes"
Nope. Probably not a math wiz, either.
Re: (Score:2)
It's just long enough that the original devs probably thought "I don't want to deal with this just yet" and put in a broken time system. Then 3 years later those devs are long gone when the bug reports start flooding in.
Complicated? (Score:5, Insightful)
I think we have different definitions of complicated.
Re:Complicated? (Score:5, Funny)
I think we have different definitions of complicated.
Evidently spelling and grammar top the list for the /. editors.
Re: (Score:2)
Well, even when it was just a leap year every 4 years, folks managed to get it wrong, and only in 4AD someone pointed out the error in how the recommendations of mathematicians/astronomers employed by Julius Caesar had been interpreted. Between the reform (45BC) and 4AD leap years happened once per 3 years.
Re: (Score:2, Insightful)
Re: (Score:2, Interesting)
unless it's the turn of the century, cuz those aren't leap years. Unless it's every fourth turn of the century, because those ones are. Hence why 2000 was a leap year, even though according to the century rule it wasn't supposed to be one. 2100 won't be a leap year.
Re: (Score:2)
No 'turn of the century year' is a leap year, since the 'turn of the century' is from XY0 -> XY1.
You're referring to the "odometer multiple digit rollover" years.
Re:Complicated? (Score:5, Informative)
Re:Complicated? (Score:4, Informative)
bool leap = !(year & 3 || !(year % 100) && year/100 & 3));
You do realize that at least on the x86 architecture that "year / 100 & 3" is two instructions, while "year % 400" will execute in the same time as "year / 100"...
Re: (Score:2)
Posts like this are why I'm glad stories like this are posted every four years or so.
inLeapYear = year % 4 == 0 && (!(year % 100 == 0) || (year % 400 == 0))
The real fun starts when you try calculating pre-Gregorian dates.
Re: (Score:2)
Re:Complicated? (Score:4, Funny)
Good news! Your troubles will be over soon!
Re: (Score:3)
Pre-Gregorian was the Julian Calendar which WAS just "year % 4 == 0". The 100/400 year exceptions were what the Gregorian Calendar changed.
Unless you mean calculating a Julian date from a gregorian date....
Revised Julian Calendar (Score:5, Informative)
And, not everyone has changed to the Gregorian calendar yet.
There's a few areas of European that refused to change from the Julian to the Gregorian, not because of any scientific reason, but because of a political reason. You see for quite a while, the main purpose of a complicated calendar was to keep track of when exactly Easter should be celebrated, and the different Orthodox churches quibbled about this. For a while, there was two different Easters, one for people on the Julian calendar, and one for people using the Gregorian.
The whole world changed to Gregorian, so they had to compromise. The compromise is one of the most hilarious developments in time tracking: the Revised Julian Calendar [wikipedia.org]
Those who follow the Revised Julian Calendar [wikipedia.org] never obey the "every 400 years" rule. Instead, they celebrate leap years every 4, unless the year is divisible by 100, unless the year is mod 900 is 200 or 600
The net result is that those countries were in agreemet with us retroactively in 1600, and in 2000, but the system will fall apart in 2400. The designers then get to live knowing that their principles have not been compromised, yet it will leave the fallout of the difference to their descendants.
Re: (Score:2)
Now wait a minute, if you're concerned about years prior to 1, you need to be concerned about the fact that leap days as we know it didn't come about until the Gregorian calendar. At the very least, you should change that > 0 to > 1582 or so (depending on where you're calculating dates). The Julian calendar is a simple % 4, without the % 100 and % 400 stuff.
Re: (Score:2)
Re:Totally agree. (Score:5, Interesting)
"Deinde, ne in posterum a XII kalendas aprilis aequinoctium recedat, statuimus bissextum quarto quoque anno (uti mos est) continuari debere, praeterquam in centesimis annis; qui, quamvis bissextiles antea semper fuerint, qualem etiam esse volumus annum MDC, post eum tamen qui deinceps consequentur centesimi non omnes bissextiles sint, sed in quadringentis quibusque annis primi quique tres centesimi sine bissexto transigantur, quartus vero quisque centesimus bissextilis sit, ita ut annus MDCC, MDCCC, MDCCCC bissextiles non sint. Anno vero MM, more consueto dies bissextus intercaletur, februario dies XXIX continente, idemque ordo intermittendi intercalandique bissextum diem in quadringentis quibusque annis perpetuo conservetur."
This quote should make the algorithm clear to any competent programmer. Note that it contains the explicit example that in the year 2000, February contains 29 days.
Of course, it can be expressed in many fewer characters in most programming languages. But the pope's astronomer didn't have any programming languages available back in 1582.
It can be fun to point out that the above Latin passage is still the "official" definition of the leap year scheme, since no standards body has tried to revise it. As far as I've been able to determine, that is; let me know if this has ever actually happened. It'd be especially fun if some standards body had tried to rephrase this in a modern language, but got it wrong. If so, they were probably shocked to discover that a 16th-century pope's edict trumped their scientific calcuations.
(The /. software guys might be able to block posting in Russian or Chinese or Arabic, but it's a lot harder to prevent people from using Latin. ;-)
Re: (Score:3)
What I like to do when people seem confused about leap-year calculation is quote them the text in Pope Gregory's definition in the February 24, 1582 document "Inter Gravissimas":
"Deinde, ne in posterum a XII kalendas aprilis aequinoctium recedat, statuimus bissextum quarto quoque anno (uti mos est) continuari debere, praeterquam in centesimis annis; qui, quamvis bissextiles antea semper fuerint, qualem etiam esse volumus annum MDC, post eum tamen qui deinceps consequentur centesimi non omnes bissextiles sint, sed in quadringentis quibusque annis primi quique tres centesimi sine bissexto transigantur, quartus vero quisque centesimus bissextilis sit, ita ut annus MDCC, MDCCC, MDCCCC bissextiles non sint. Anno vero MM, more consueto dies bissextus intercaletur, februario dies XXIX continente, idemque ordo intermittendi intercalandique bissextum diem in quadringentis quibusque annis perpetuo conservetur."
Yep. That cleared it right up!
Re: (Score:2)
http://en.wikipedia.org/wiki/Leap_second
Re: (Score:2)
Well, I'm puzzled by this. How could it be "lost in translation" when that was the original text? It wasn't (mis)translated from any other language. That's what the pope's astronomer wrote. Actually, the edict was a bit longer than that. The whole thing is online [bluewaterarts.com], along with some pretty good translations to French and English, and there seems to be no mention of any time unit smaller than a day.
But I'll have to remember this omission, the next time the all-knowing nature of our religious leaders co
Now's your chance? (Score:2)
I'm pretty sure the math doesn't go anywhere. It's not Brigadoon.
In fact I'm going to take the URL and put it in my calendar for next June.
Will report back ....
Lets use the Myan Calendar (Score:2)
Re:Lets use the Myan Calendar (Score:5, Funny)
Re: (Score:2)
Nice sig, btw.
Re: (Score:2)
And tasty they were!
Re: (Score:2)
Re: (Score:2)
Why not? They dont know when jesus was born so they took the winter soltise and said this is when we celebrate.
Re: (Score:3)
Oh wait, it ends in 2012!
No, it doesn't... just most of the digits turn to "0"... in fact, the remaining radial digit of the number representing the year will not be a "1" either, as in when we moved from 99 A.D. to 100 A.D. No, in fact, they were already on the 12th cycle, so the calendar already could express more years than just 2012 A.D. and we never had to add anything to their calendar system to do so...
Knowing the rules (and not just for leap day) (Score:5, Interesting)
One of my first projects in Computing and Algorithms I in college was to make a calendar that would print out in console with days correctly placed on the day of the week. The instructions specified to take special care for leap day; everyone thought they understood leap day, so no one bothered to check on the rules. The fact that round centuries do not include a leap day except when (year mod 400 = 0) meant that every one of our calendars[1] was wrong for certain years (but right for others, IIRC). And our professor docked us points as such. Back then, the entire class (along with myself) felt that we were misled or cheated, but looking back on it now that was an important lesson on project management, specifically researching requirements and checking with the interested party about how things are.
I reckon this lesson was missed by many, which leads to the various issues we see for software on Leap Day, including Microsoft's Azure as mentioned in a recent /. article.
[1] For the half of the class that completed the project, this 101 class was used to weed out those who couldn't actually program for crap and the EEs just needed a C to meet their requirement.
Wait, what? (Score:5, Funny)
Re: (Score:3)
Today is Feb 29, a leap day, that's why it's relevant. Tomorrow, it will be far less so.
A video with visualisations (Score:3, Informative)
Four days too late! (Score:5, Informative)
The extra, or "bissextile" day is actually inserted immediately after February 23.
The Romans picked up the Egyptians' idea of treating a common year as 360+5 days, since 360 is a highly composite number and all (the Mayans ended up doing the same). But instead of treating the extra 5 days as "epagomenal" (outside any month), they were treated as the last five days before the first month of spring, i. e. the last five days of February.
Treating the five-day block of Feb 24 through Feb 28 as inviolate meant inserting the extra day (previously an extra month) before it.
This is why the Christian feast of Saint Matthias has historically been observed on February 24 in common years and February 25 in leap years; it's always the fifth ("sixth," if you lack an understanding of zero) day before the calends of March.
Re: (Score:2)
Er, five days too late.
Fuck my non-life.
leap days make ood codeing bugs show up some times (Score:3)
http://thedailywtf.com/Articles/DATE_NOT_FOUND.aspx [thedailywtf.com]
Misidentifying the source of the problem (Score:2)
When code does not correctly model the problem domain, the error isn't with the domain.
Who are we kidding? The real reason for leap days: (Score:2)
To give first-time programming students a fun and interesting homework assignment.
WTH? (Score:2)
Whats with all the leap stuff?
Yes, I know it's a leap year, but the only other time I remember seeing so much stuff about it being circulated was in 2000.
Still, why are adults explaining it to other adults? Is this one different? Is the world getting so mellow that a leap year is no an excuse for a lengthy discussion on a reletivly trivial event? Trivial in that the rules are pretty simple. Not trivial as in little impact.
Re: (Score:2)
A modest proposal (Score:2)
There's a very, very simple solution to this, and that is: At some value UTC, we all light model rocket engines with the exhaust facing east, and slow down the day such that its length goes evenly into a year. Any over/undershoot in the quantity or duration of burns can be adjusted on a much smaller scale. After that we just perform regular burns in the opposite direction to maintain angular momentum. Voila!
drop astronomy for Planck units (Score:2)
Re: (Score:2)
There's an extra working day! Woohoo!
Actually there is more like 5/7 of a working day, right?
Re: (Score:2)
We're both on /.
I wouldn't really say we're getting a lot of WORK done.
Re: (Score:2)
No there's an extra working day.
We get an extra Monday this year - if it wasn't a leap year then Dec 31 would be Sunday and that Monday would be part of next year.
Re: (Score:2)
There's an extra working day! Woohoo!
Also one more day before you need to pay the monthly mortgages and bills. February can be hard on people who are on a tight budget.
Re:Our whole calendar is messed up. (Score:5, Insightful)
The whole 7 day week is rather random too- based on some out-of-date dogma that is probably mistranslated. (the original word in Genesis translated as "day" was more accurately "a period of time" although it was often "day" but not necessarily) - so we force the meaning of "day" onto it and have a 7 day week. Silly number.
Let's make a week 10 days- a much more logical number.
Actually 7-day week makes sense if you have a 28-day month.
Re: (Score:2)
Actually I'm pretty fond of the 7-day week, but maybe months should be a nice round number of days, like 32. Then we'd get an extra day of weekend.
Re: (Score:2)
Every month has 28 days.
Re: (Score:2)
That's right -- a war on Chistmas!
Re: (Score:2)
I have been ranting about a 13 month year to my coworkers for about a year now. 12 months would have 28 days. The last month would have 29 days. Every leap year the last month would have 30 days. A lot of companies would be giving an extra day of vacation every four years.
Re: (Score:3)
We should just have star dates.
Re: (Score:2)
Why is it everyone has their own scheme for rebuilding Calendars?
And why so much significance tied to the winter solstice? That hardly matters anymore in a global economy.
Re: (Score:2)
Solstice is significant because it is not an arbitrary day- it is a measurable location on earth's flight. Jan 1 is just arbitrary with no scientific marker. It is very likely when the calendar were first created they intended it to be on the solstice- but human ineptitude made it drift to what is Jan 1 today.
Re: (Score:3)
The oldest known version of the Roman calendar that became the calendar we have now had its start date fixed to the vernal equinox, actually.
Jan. 1 wasn't reached by the date floating because the calen
Re: (Score:2)
Re:Our whole calendar is messed up. (Score:5, Insightful)
Exactly my point.
Nobody's going to listen to any ideas of changing this at this point because there is no need, and a lot of pain involved.
If you planned it for 10 years you would still have 50% of our automated infrastructure stuck on old time keepers. Bazillions of contracts, deeds, etc would need rewrite, and virtually all historical texts would need corrections.
The only place where there is anything to gain is in date computations in computers, and we have that solved.
Its a mess, but not a debilitating one.
Converting to any other system would be all pain, and zero gain.
Re:Our whole calendar is messed up. (Score:4, Interesting)
Re:Our whole calendar is messed up. (Score:5, Informative)
Our whole calendar is messed up. First- Jan 1st is a poor start date.
I suspect the original pioneers intended the year to start on the Winter Solstice-
Yes, but Julius Caesar decided to start it on the first new moon following. And based on the best data available at the time, every 19th year would have started on a new moon (see below).
which is more like Dec 21st most years on our calendar.
More like Dec 25 at the time, hence the date of Christmas.
So- The year should start on Dec21st.
It took almost 2500 years for everyone to agree to start their year with January (instead of March). George Washington himself was fuzzy on what year he was born. Now, after just getting things straightened out (on a relative time scale), you want to fuck with it again?
Then- our months are supposed to be based on cycles of the moon (Approx every 28 days)-
29.5 days. The usual approximation is alternating months of 29 days and 30 days in length.
but because there were 13 and superstitious nitwits didn't like 13 we have 12 months with varying days.
13-month years work for all the cultures with a lunar calendar, e. g. the Jews and the Chinese. The biggest problem is reckoning when the 13th month gets added. If you treat the tropical year as 365 days, you have to add an extra synodic month 7 times in 19 years (Metonic cycle). If you use 365.25 days for a tropical year, it's more accurate to say that 28 are added in 76 years (Callippic cycle). And if you're using the even-more-accurate 365.2425-day approximation... well, go search for the term "epact."
The whole 7 day week is rather random too-
Try counting the number of days between the first visibility of the new crescent moon and first quarter. Only your eyes and your ability to estimate the illumination of the moon are allowed.
based on some out-of-date dogma that is probably mistranslated. (the original word in Genesis translated as "day" was more accurately "a period of time" although it was often "day" but not necessarily)
If you're referring to chapter 1, note that "day" is always paired with "night."
Let's make a week 10 days- a much more logical number.
Revolutionary France called, they want their "decades" back.
Regardless, (365 mod 7) = 1 while (365 mod 10) = 5.
So we have 36 weeks in a year. If we MUST have a bigger break- we can divide these into 9 months of 4 weeks each.
Even Revolutionary France understood the importance of the four seasons, with agriculture being the foundation of modern civilization and all.
We would then have 5 or 6 days at the end- a "half week"
Coptic Egyptians want their "epagomenal days" back.
Not perfect- but based more on logic than our current system and no-silly formulas needed (other than determining the solstice)
And you would once again have devised a calendar system that focuses on rationalism at the expense of pragmatism and utility, using many ideas have have been tried for centuries or even millennia. Here's what you'd be abandoning:
In fact, 2, 4 and 6 above were deliberate design choices on the part of Julius Caesar specifically to keep things simple.
Re: (Score:2)
I'll take you up on your rebuilt calendar, after you get all mail servers and mail clients to use a replacement for SMTP, to prevent spam (or at least make it 100% reliably traceable/non-forgeable, and not have to need filters on the client end).
Re: (Score:3)
Re: (Score:2)
Our whole calendar is messed up. First- Jan 1st is a poor start date.
I suspect the original pioneers intended the year to start on the Winter Solstice...
Good guess, but there is not a lot of evidence to support that theory. In pre-Roman cultures, the Vernal Equinox was more commonly selected as the start of the year. The Calendar of Romulus, from about 753 BC, used the Vernal Equinox as the start of the year. It ran for ten months (304 days), followed by a number of days of winter, which were not considered part of any month. The Julian Calendar, starting in 45 BC, used January 1 as the start of the civil calendar year but the calendar was designed with
Re: (Score:3)
All start dates are equally arbitrary, so Jan. 1 is as good as anything else.
No, The starting day of the year under the old Roman Republican system (from which our modern system evolved by way of the Julian and Gregorian reforms) was whatever day happened to start the Roman consular term (since years weren't numbered, they were named after the consuls in offic
Re: (Score:2)
Its a completely arbitrary number. Matching up with the median number of fingers a human has doesn't make it a "logical number".
I think you mean the mode. It is highly unlikely the median is exactly 10.
Re: (Score:3)
Let's make a week 10 days- a much more logical number.
So we have 36 weeks in a year. If we MUST have a bigger break- we can divide these into 9 months of 4 weeks each.
The French Republic did exactly that. Their calendar had 10 days in a week, 3 weeks in a month, 12 months in a year. That calendar remained in effect for 12 years, until it was abolished by Napoleon.
They also introduced decimal time (100 seconds in a minute, 100 minutes in an hour, 10 hours in a day).
Re: (Score:2)
You jump back and forth between wrong and right.
For someone who pretends to know so much, I'm surprised you don't know that originally there were ten months: Dec{imal,ember). December, according to its name is supposed to be the tenth month.
Correct
But thanks to some caesar named Augustus we have one extra. I'll leave the origin of the other added month as an exercise for you.
Often repeated, but not correct. There had been twelve months long before Augustus was born.
And in early Roman times the year used to start in March, closer to the Vernal equinox,
And back to correct.
They originally had 10 months of roughly 30 days each, plus a period called 'winter' that was just kind of there to fill in the rest of it. Some time around 700BC give or take (pre-Republic, still during the Monarchy) 'winter' was converted to the months of January and February, which were added to the beginning of the year.
The months of Jul
Re: (Score:2)
It's fine with me. The main part of the number is the same size than the lowercase letters, and some of the numbers have ascenders and descenders - making them very similar in their typographic character than normal english text with lots of lowercase letters, some of them with ascenders and descenders, and a few uppercase letters thrown in for good measure.
Re: (Score:2)
Which font are you talking about?
That's how numerals used to be. It does make the numbers fit better with lower case text, which does the same thing. The "modern" variety with 0123456789 all the same height are more like "upper case" numbers.
Granted, a lot of the time when we use figures, it's in a context where upper case makes sense, but not always. Inside a text, it may very well be more readable if 3-4-5-7-9 dip down just like some letters do.
Then again, if you grew up with a font where g-j-p-q-y did
Re: (Score:2)
Was that a common occurrence? The situations I seem to remember running into it were lowercase mods for Apple ][ / ][+, and perhaps non-Apple 80 column cards for //es.
Re: (Score:2)
Wiki page. [wikipedia.org]
According to this, hand-written Arabic numerals from the 12th Century tended to be this way; "Titling figures" (numerals with consistent baseline and height) seems to have been an 18th Century "innovation".
Personal observation: The wiki page in question features an image of numeral glyphs from the Hoefler Text face, one of the most beautiful typefaces ever invented IMHO.
Re: (Score:2)
More readable numbers without l33t sTudLy caps are quite an innovation in my book. Nautical numbers had that form only due to their Arabic legacy, but once merchants' accounting went full steam, people realized how much easier working with tabular data is if your number glyphs are aligned.
Re:In Soviet Russia... (Score:5, Funny)
e.g.; "In Soviet Russia, year leaps you! Ha ha ha." (there's no way to spell Yakov's laugh)
Re: (Score:2)
(there's no way to spell Yakov's laugh)
Sure there is:
!ah ah aH
Re: (Score:2)
Won't work. The orbital period around the sun isn't constant. We're not (yet) locked in a fractional orbital sync with Jupiter, so its pull affects the nominal year length.
365.2421904 is a good approximation for right now, and the 4*25*4 rule is "good enough" for a while - locking it wouldn't make things better.
Plus, you don't really want the day to be in sync with the orbital year. Midday would not not occur at noon anymore, but shift, because perhelion doesn't happen at the same time of day every year.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Ashamed to admit it, but in 1988 took advantage of the fact that 2000 was a leap year, and the fact that I doubted my system (an artillery control system) would still be in use in 2100 to simplify some leap year logic to simply year % 4.
Turns out I wasn't pessimistic enough... Obsoleted by 1998.