Slashdot Mirror


The Math of Leap Days

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."

225 comments

  1. Duh. by masternerdguy · · Score: 3, Funny

    There are no leap years. It's a conspiracy to cause IT nightmares and bratty kids who claim their age /= 4.

    --
    To offset political mods, replace Flamebait with Insightful.
    1. Re:Duh. by jellomizer · · Score: 2

      Not that much of a Nightmare, at least with modern Data classes. You take the month and year you are looking at. date(Year, Month+1, Day = 1) - 1 day. Then you get the last day of every month. Leap Year isn't the nightmare, The nightmare is the normal Month system with different days each month.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    2. Re:Duh. by Anonymous Coward · · Score: 0

      Except those same Date classes also have a function that tells you the number of dates in a given month of a given year, so no nightmare there at all.

    3. Re:Duh. by kirkb · · Score: 4, Informative

      No, the REAL nightmare for programmers is daylight savings time. Especially in the spring, when local times jump back and repeat. Ugh.

      --
      Slashdot: come for the pedantry, stay for the condescension.
    4. Re:Duh. by egamma · · 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.

    5. Re:Duh. by Anonymous Coward · · Score: 0

      Is that UTC format with or without leap seconds?

    6. Re:Duh. by blueg3 · · Score: 3, Interesting

      UTC includes leap seconds. TAI does not.

    7. Re:Duh. by Anonymous Coward · · Score: 0

      That's actually not a very good idea for a number of reasons.

      First, going out of/into DST you have times that occur twice or not at all (making it impossible to reliably convert back to local time). Second, if your date is in the future there's a chance the rules will change, so you'll save with one rule and convert back with another, and mess your time up. Finally, it makes reports that constrain values by local time a problem, because the database doesn't typically have access to those conversion routines, and even if it does, it can't make them sargable for a query.

      kirkb is right: it's a nightmare.

    8. Re:Duh. by EdIII · · Score: 1

      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 on DST being constant year by year.

      Anybody wondering why UTC "solves" the problem it is because it allows you to specify time zones. You can specify EDT on the east coast of the US when DST is active and EST when it is not. This allows you to store the time with not just the time zone, but actually say whether or not the time had DST applied to it already.

      Of course, this once again, relies on whether the system and code performing the reading and storage of time has DST operating correctly and stores EDT instead of EST when appropriate. Just having -400 or -500 at the end is insufficient to fully account for DST and allow the "OS" the ability to interpret it correctly.

      Relying on the "OS" all the time is not the greatest idea too. It could very well be inconsistent across different platforms. If the data is intended for reports and displays I would rather convert it at the API level in a consistent fashion and transmit that in any kind of response document that is requested.

    9. Re:Duh. by Anonymous Coward · · Score: 0

      I agree with the storing of time in UTC to eliminate confusion. The problem I see is not all OSes will translate that UTC time back the same way! Create a file at noon each day then after a daylight saving event go back and look at the files you created earlier. Does that older file still show a time of 12 noon or does it now show 11:00am or 1:00pm? Unix OS seems to translate the time based on DST rules in effect when the file was created/modified. Windows OS seem to translate the time based on DST rules in effect by the system's current time. It is matter of option which view is correct. But please, when calculating pay for hours worked, do all the math in UTC time, thank you.

    10. Re:Duh. by Darinbob · · Score: 0

      IT nightmares? It's all automatic. Unless you've got some broken operating system from Microsoft...

    11. Re:Duh. by Darinbob · · Score: 1

      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.

    12. Re:Duh. by Darinbob · · Score: 1

      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 you can tell quickly which designs are fundamentally flawed. I've seen bug fixes that convert from stored local time to UTC and then back to a different local time.

    13. Re:Duh. by EdIII · · Score: 1

      strings are all multibyte

      I assume by multibyte strings you mean Unicode right? I agree with that. There is no real reason why we should not be moving to Unicode everywhere.

      Everything internally is UTC or at last based on something other than local time

      That does not make any sense to me. Everything in UTC format represents a "local" time. That is what the EDT/EST is for, or the -400. It is able to indicate time zones. It can also indicate DST if you use it right.

      Perhaps you mean that all time is stored relative to zero, or a single time zone regardless of where you actually are? A lot of global companies do that. I store everything in the Pacific/Los Angeles time zone. Time zone is just a preference for reports and interfaces. I process the time at the API level and return the time in the requested time zone, or Pacific by default. All times are formatted to indicate the time zone anyways, so the locale settings can still be applied.

      The only time you deal with locale settings is just before outputting the values and just after inputting them.

      The problem you have is that you want it *raw* and unprocessed. It can't be, because as I said you would need to store it *first* and that does not solve the problem of DST though anyways.

      Wherever you are getting the time from, it had to be read from a system. That system had to be configured for its UTC timezone, and have DST configured.

      You have two choices:

      1) Represent the time in the EST time zone with -400 or -500.
      2) Represent the time in the EST time zone with EDT or EST.

      #1 results in a data record in which you only know the time zone, but not the state of DST at the moment it was recorded. The difference between -400 or -500 does not allow us to conclude if it was DST responsible, or if the event actually occurred in a different time zone.
      #2 results in a data record in which you explicitly know that it was the -400 time zone, but that it was also when DST was off or on.

      I would think you would want to represent the state of DST in the time stamp. When you go to process locale settings for the output you have information that is quite valuable and definitive. Not everywhere in the world even uses DST. It would be useful to know right from the UTC format if it was recorded in a DST time zone and if DST was actually on.

      There is no way to store the time stamps "untouched". It has to be, otherwise you have ambiguous values with respect to DST. It's simpler to just store DST state information in the time stamp itself and if it is missing, add it. That way you can always be sure about the time.

    14. Re:Duh. by batkiwi · · Score: 4, 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".

    15. Re:Duh. by Darinbob · · Score: 1

      No, not necessarily unicode. That's still sort of controversial in some places and I first came across this idea when unicode was pretty rare. Ie, you use the format your customer wants and which is their national standard without lecturing them. But it doesn't matter what the internal format is as long as you can convert it when needed. That converted a project that many thought would take a few months into just a couple of weeks.

      UTC is a universal time. It doesn't matter again actually what format you use, as long as it's consistent and not tied to any "local" representations. Ie, the format most people use is "number of seconds since 1/1/1970 GMT", no notion of DST is in there at all. It's a neutral format with time relative to a fixed point. It certainly does have drawbacks of course, it doesn't represent a lot of dates very well except for those within a handful of decades of 1970. But it's easy to convert to local time, and there's a standard well maintained database to do this.

      If you store a locale specific time then you have to store additional information that describes the local time zone. The mistake I see a lot of developers doing is using local time but not including this local time zone info and assuming their application or system never crosses time zone boundaries. That was the problem with Windows, it stores local time on the computer and thus has to do extra work during time changes or update the hardware time when you change time zones.

      Most of the time only need to know the time zone and DST rules when inputting the time/date and when outputting it. The exceptions are if you need to do date oriented calculations (ie, number of weeks between two times) or you have an application reason to use local time (an activity that must happen at midnight local time (usually you sleep for 24 hours but sometimes it's 23 or 25 hours).

      It's just very rare to want to know whether or not DST was on or off in the first place. But if you've got your time zone database and you know the locale in question, you can always get this information if you have the UTC time (it's a standard function in many languages). It's more likely that someone wants both time and location for a particular event or record, and those should be stored separately instead of cramming location into a "EST" suffix.

    16. Re:Duh. by Hognoxious · · Score: 1

      That does not make any sense to me. Everything in UTC format represents a "local" time.

      Find out what the U stands for. It might make sense then.

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    17. Re:Duh. by EdIII · · Score: 1

      You mean universal? That just means a standard.

      A UTC formatted time stamp always contains a time zone, so it always represents a time local to somewhere. Even if it is missing the time zone it just means that it is local to Greenwich I think since you would have to assume it to be -0/+0.

      The poster was saying to base it off UTC or something other than local time. In that context it does not make sense because UTC always refers to a time zone somewhere. Your local time zone would be as good as any other place.

    18. Re:Duh. by Man+Eating+Duck · · Score: 2

      Not that much of a Nightmare, at least with modern Data classes. You take the month and year you are looking at. date(Year, Month+1, Day = 1) - 1 day. Then you get the last day of every month. Leap Year isn't the nightmare, The nightmare is the normal Month system with different days each month.

      Way too complicated :)

      Just convert whatever date or timestamp to/from Julian Day (the astronomical one, not ordinal day), and compare the results before and after. Very robust, functions exist in most languages (if not, the algorithm is trivial), and your dates are automagically validated. It will also handle the different-number-of-days-in-a-month problem for you.

      While you're at it: <rant>

      * If your data input expects dates in any formmats but ISO 8601, you're doing it wrong
      * If you're not using Unicode, you're doing it wrong (I blame English-centric programmers testing with lorem ipsum for this one)
      * If you must write a "char sep;"-separated input format, don't use any separator that WILL occur in normal text data (comma/semicolon-guys, I'm looking at you)
      * Document what you're expecting, don't leave me to guess...

      There are more issues which should be non-issues, but these simple rules should be beaten into every programmer's head the first day at any programming-related course, and every day after that. Just a few days ago I had the pleasure of writing code which dumped data from a well-structured DB to an accounting system which demanded two different (unspecified) date formats for two columns in the same freaking row, used semicolon separation even if there were obviously user-inputted "comment" fields (with no documented escapes), and croaked on Unicode input.

      </rant>, but seriously, the astronomical date thing makes date validation foolproof and throws in trivial arithmetic time period calculation for free in a portable manner. Check it out if you ever need to handle dates in your code.

      --
      Are you a grammar Nazi? I'm trying to improve my English; please correct my errors! :)
    19. Re:Duh. by mwvdlee · · Score: 1

      AFAIK, this is effectively what most databases do with timestamps; they store time as UTC + named timezone (of the database server).
      It's easy to extract UTC, local time and timezone from a timestamp.

      --
      Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
    20. Re:Duh. by xaxa · · Score: 4, 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)

    21. Re:Duh. by Anonymous Coward · · Score: 0

      "saving", not "savings".

    22. Re:Duh. by xaxa · · Score: 1

      I agree with the storing of time in UTC to eliminate confusion. The problem I see is not all OSes will translate that UTC time back the same way! Create a file at noon each day then after a daylight saving event go back and look at the files you created earlier. Does that older file still show a time of 12 noon or does it now show 11:00am or 1:00pm? Unix OS seems to translate the time based on DST rules in effect when the file was created/modified. Windows OS seem to translate the time based on DST rules in effect by the system's current time. It is matter of option which view is correct.

      Certainly not! If I make a file at 2012-03-01 12:00 +0000 (my local time right now, in London), then make another on 2012-06-01 12:00 +0100 (during British Summer Time), the second file was actually made at 2012-06-01 11:00 +0000. The first file was made at 2012-03-01 11:00 +0100.

      Note that GNU ls converts times into the local time for display, using whatever the date of the file is. GNU touch converts the input time in the same way.
      $ touch -t '201203011200' winter-midday
      $ touch -t '201206011200' summer-midday
      $ ls -l
      -rw-r--r-- 1 0 2012-06-01 12:00 summer-midday
      -rw-r--r-- 1 0 2012-03-01 12:00 winter-midday
      $ ls -l --full-time
      total 0
      -rw-r--r-- 1 0 2012-06-01 12:00:00.000000000 +0100 summer-midday
      -rw-r--r-- 1 0 2012-03-01 12:00:00.000000000 +0000 winter-midday
      $ TZ=0 ls -l --full-time
      -rw-r--r-- 1 0 2012-06-01 11:00:00.000000000 +0000 summer-midday
      -rw-r--r-- 1 0 2012-03-01 12:00:00.000000000 +0000 winter-midday

    23. Re:Duh. by dj245 · · Score: 1

      The real conspiracy is getting everyone on salary to work an extra day for the same pay.

      --
      Even those who arrange and design shrubberies are under considerable economic stress at this period in history.
    24. Re:Duh. by petermgreen · · Score: 1

      Everything should be in UTC.

      NO NO NO

      Using UTC for everything is NOT a soloution because you cannot reliablly convert a future time between local time and UTC (the conversion rules could change at any time) and since the real world runs on local time you need to be able to schedule events at a future local time.

      The proper soloution is to store both the time of an event and the timezone that event is defined in. Then when a new set of rules come along you have to process the new rules and generate a set of warnings about any new conflicts introduced and any events that have moved relative to each users local time.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
  2. For years by Sez+Zero · · Score: 5, Funny

    and it only comes along every for years.

    Wow! That really IS rare!

    1. Re:For years by oodaloop · · Score: 2

      The slashdot editors were probably just reading an alien cookbook and got confused.

      --
      Tic-Tac-Toe, Global Thermonuclear War, and relationships all have the same winning move.
    2. Re:For years by neokushan · · Score: 1

      for(int years = 0; years LENTH_OF_UNIVERSE; i++) { /* article */ }

      --
      +1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
    3. Re:For years by Anonymous Coward · · Score: 2, Funny

      That must be the American spelling: there's no "u".

    4. Re:For years by daveywest · · Score: 1

      The person who wrote the summary was a math wiz, not an english major.

    5. Re:For years by spatterson · · Score: 1

      God damn that was an epic fail

    6. Re:For years by Smallpond · · Score: 2

      "The Bad Astronomer writes"

      Nope. Probably not a math wiz, either.

    7. Re:For years by Darinbob · · Score: 1

      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.

    8. Re:For years by neokushan · · Score: 2

      Slashdot's crap filter didn't help.

      --
      +1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
    9. Re:For years by roothog · · Score: 1

      You're on slashdot and you don't know who the Bad Astronomer is? Pretty sure he's good at math.

  3. Complicated? by Anonymous Coward · · Score: 5, Insightful

    I think we have different definitions of complicated.

    1. Re:Complicated? by Meshach · · Score: 4, Funny

      I think we have different definitions of complicated.

      Evidently spelling and grammar top the list for the /. editors.

      --
      "Maybe this world is another planet's hell"
      Aldous Huxley
    2. Re:Complicated? by Anonymous Coward · · Score: 0

      Agreed. I had to write an algorithm for checking if a year was a leap year. It can be done in one, non-wrapping, line of code.

    3. Re:Complicated? by Talderas · · Score: 0

      if (year % 4 == 0) ?

      --
      "Lack of speed can be overcome. In the worst case by patience." --Znork
    4. Re:Complicated? by Anonymous Coward · · 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.

    5. Re:Complicated? by KiloByte · · Score: 1

      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.

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    6. Re:Complicated? by Anonymous Coward · · Score: 2, Insightful

      In APL I could do it in four characters without any of those wimpy spaces and other noise.

    7. Re:Complicated? by Forty+Two+Tenfold · · Score: 4, Informative

      bool leap = !(year & 3 || !(year % 100) && year/100 & 3));

      --
      Upward mobility is a slippery slope - the higher you climb the more you show your ass.
    8. Re:Complicated? by 19thNervousBreakdown · · Score: 1

      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.

      --
      <xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
    9. Re:Complicated? by Anonymous Coward · · Score: 0

      ( ((year)>0) && !((year)%4) && ( ((year)%100) || !((year)%400) ) )

    10. Re:Complicated? by viperidaenz · · Score: 1

      Calendar cal = Calendar.getInstance(); cal.set(year, Calendar.FEBRUARY, 1); boolean leap = cal.getActualMaximum(Calendar.MONTH) == 29; As long as your timezone data in the JVM is correct, will work for any year post or pre gregorian

    11. Re:Complicated? by 19thNervousBreakdown · · Score: 1

      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.

      --
      <xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
    12. Re:Complicated? by neokushan · · Score: 2

      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....

      --
      +1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
    13. Re:Complicated? by Anonymous Coward · · Score: 0

      I use the Mayan calendar, you insensitive clod!

    14. Re:Complicated? by mattack2 · · Score: 1

      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.

    15. Re:Complicated? by Anonymous Coward · · Score: 0

      If you're worried about Gregorian calendar vs. Julian calendar, you have a bigger problem.

    16. Re:Complicated? by Yvan256 · · Score: 3, Funny

      Good news! Your troubles will be over soon!

    17. Re:Complicated? by 19thNervousBreakdown · · Score: 1

      Well then why put the > 0 check in there if you're not worried about dates prior to 1582?

      --
      <xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
    18. Re:Complicated? by Anonymous Coward · · Score: 0

      Doesn't want to deal with an undefined number.

    19. Re:Complicated? by Anonymous Coward · · Score: 1

      bool leap = !(year & 3 || !(year % 100) && year/100 & 3));

      Oh yeah? For what years and locales? There is a member of congress with an uncle born on February 30, 1931

      Do the world a favor and use a calendar library. Your simplistic OTTOYH attempt is why most programming bugs exist.

    20. Re:Complicated? by snowgirl · · Score: 3, 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"...

      --
      WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
    21. Re:Complicated? by Forty+Two+Tenfold · · Score: 1

      You're absolutely on both accounts ;)

      --
      Upward mobility is a slippery slope - the higher you climb the more you show your ass.
    22. Re:Complicated? by Forty+Two+Tenfold · · Score: 1

      Do the world a favor and use a calendar library.

      No.

      --
      Upward mobility is a slippery slope - the higher you climb the more you show your ass.
    23. Re:Complicated? by Anonymous Coward · · Score: 1

      bool leap = !(year & 3 || !(year % 100) && year/100 & 3));

      Oh yeah? For what years and locales?

      For all years and locals using the Gregorian calendar.

      There is a member of congress with an uncle born on February 30, 1931

      I would say citation needed, but I already know that February 30 existed from 1930-1931 in the Soviet Union after they introduced a revolutionary calendar in 1929. So the identity of of this congress critter and uncle are not really needed.

      Your simplistic OTTOYH attempt is why most programming bugs exist.

      Your arrogant and misguided post is why so many slashdotters ignore posts made by Anonymous Cowards.

    24. Re:Complicated? by similar_name · · Score: 1
      From Wikipedia

      Turn of the century, in its broadest sense, refers to the transition from one century to another. The term is most often used to indicate a non-specific time period either before or after the beginning of a century.

    25. Re:Complicated? by spaceyhackerlady · · Score: 1

      if (year % 4 == 0) ?

      Actually, this is the algorithm I use. The next time it will be wrong is in 2100, and I don't expect to still be around, nor do I expect any code I've written to still be running.

      I also see nothing complicated with elementary school arithmetic, but I guess that's just me.

      ...laura

    26. Re:Complicated? by Anonymous Coward · · Score: 0

      bool leap = !(year & 3 || !(year % 100) && year/100 & 3));

      You have 2 opening parentheses and 3 closing...

    27. Re:Complicated? by mattack2 · · Score: 1

      A whole year off is quite a long "non-specific time period".

    28. Re:Complicated? by Anonymous Coward · · Score: 1

      Easier:

      bool leap = (year % 4 == 0) && (year % 100 != 0) || (year % 400 == 0);

    29. Re:Complicated? by similar_name · · Score: 1
      How about define: turn of the century

      the period from about ten years before to ten years after a new century.

    30. Re:Complicated? by PsyberS · · Score: 1

      Actually, this is the algorithm I use. The next time it will be wrong is in 2100, and I don't expect to still be around, nor do I expect any code I've written to still be running.

      Sounds like the logic people used when deciding that storing years with 2 digits was a good idea. How did that turn out?

    31. Re:Complicated? by secretsquirel · · Score: 0

      fine

    32. Re:Complicated? by Hognoxious · · Score: 1

      s/1582/1752/ you bead jiggling clod!

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    33. Re:Complicated? by Forty+Two+Tenfold · · Score: 1

      No, it's just dumber and slower. You have one division instead of way faster bitwise AND, a bunch of unnecessary comparisons and longer boolean logic.

      --
      Upward mobility is a slippery slope - the higher you climb the more you show your ass.
    34. Re:Complicated? by Forty+Two+Tenfold · · Score: 1

      "year % 400" will execute in the same time as "year / 100"...

      I wouldn't be so sure. AFAIK x86 CISC is actually RISC + macros, so MOD is actually DIV + MUL + SUB, therefore slower than DIV + ANL.

      --
      Upward mobility is a slippery slope - the higher you climb the more you show your ass.
    35. Re:Complicated? by snowgirl · · Score: 1

      "year % 400" will execute in the same time as "year / 100"...

      I wouldn't be so sure. AFAIK x86 CISC is actually RISC + macros, so MOD is actually DIV + MUL + SUB, therefore slower than DIV + ANL.

      ... no, it's not. DIV and MOD can be calculated at the same time. And in fact, the most efficient way to calculate a quotient (short of a hardware lookup table) in circuitry actually does calculate the two at the same time.

      In the x86 architecture, it is defined by the Instruction Set Architecture that the DIV operation calculates both the quotient and modulo at the same time.

      --
      WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
    36. Re:Complicated? by Anonymous Coward · · Score: 0

      On x86, the division instruction also calculates the remainder. So (year%100) will give you year/100 with zero instructions. Since division and modulus are slow, it is much faster as originally written.

    37. Re:Complicated? by snowgirl · · Score: 1

      On x86, the division instruction also calculates the remainder. So (year%100) will give you year/100 with zero instructions. Since division and modulus are slow, it is much faster as originally written.

      *fiddles around with some gcc -S...*

      Yep. You're right, I hadn't thought of that.

      Although, since this is all boolean math anyways, the ands and ors are typically dealt with by using flow control anyways... since the "||" short-circuits the division entirely, both versions will run at the same speed 3 out of every 4 years. And the !(year % 100) would short-circuit the "&&" for all but every one-hundred years, so the only time that the speed difference would have made a difference was in the year 2000, and will again make a difference in 2100, and every hundred years after.

      So, indeed, it is faster, but not really an efficient use of time to optimize...

      Weirdly, when I compiled without any optimization flags on the command-line, it turns the idivl into a few imull's, with some shifting, and subtracting...

      --
      WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
    38. Re:Complicated? by Anonymous Coward · · Score: 0

      x86 division returns both the remainder and quotient. If optimized by the compiler, the year/100 is free.

  4. U.S. GDP predicted to rise .3% in 2012 by Anonymous Coward · · Score: 0

    There's an extra working day! Woohoo!

    1. Re:U.S. GDP predicted to rise .3% in 2012 by nitehawk214 · · Score: 1

      There's an extra working day! Woohoo!

      Actually there is more like 5/7 of a working day, right?

      --
      I'm a good cook. I'm a fantastic eater. - Steven Brust
    2. Re:U.S. GDP predicted to rise .3% in 2012 by Beardo+the+Bearded · · Score: 1

      We're both on /.

      I wouldn't really say we're getting a lot of WORK done.

      --

      ---
      ECHELON is a government program to find words like bomb, jihad, plutonium, assassinate, and anarchy.
    3. Re:U.S. GDP predicted to rise .3% in 2012 by arth1 · · Score: 1

      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.

    4. Re:U.S. GDP predicted to rise .3% in 2012 by nedlohs · · Score: 1

      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.

    5. Re:U.S. GDP predicted to rise .3% in 2012 by nitehawk214 · · Score: 1

      I will agree here. The upshot is that we get more weekdays than weekends.

      --
      I'm a good cook. I'm a fantastic eater. - Steven Brust
  5. Now's your chance? by LMacG · · Score: 1

    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 ....

    --
    Slightly disreputable, albeit gregarious
  6. Its not that hard by suso · · Score: 5, Interesting

    On climagic I laid it out in less than 140 characters.

    1. Re:Its not that hard by Anonymous Coward · · Score: 2, Funny

      ARRGH, a twitter feed I acutally want to follow.

  7. Bad font! by Stickybombs · · Score: 1

    Does anyone else really dislike the way that font represents numbers, constantly bouncing up and down above and below the rest?

    1. Re:Bad font! by Sique · · Score: 1

      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.

      --
      .sig: Sique *sigh*
    2. Re:Bad font! by arth1 · · Score: 1

      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 didn't have descenders, you might think otherwise. We could decrease line spacing if it wasn't for those five pesky letters...

    3. Re:Bad font! by mattack2 · · Score: 1

      Then again, if you grew up with a font where g-j-p-q-y didn't have descenders, you might think otherwise. We could decrease line spacing if it wasn't for those five pesky letters...

      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.

    4. Re:Bad font! by idontgno · · Score: 1

      Wiki page.

      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.

      --
      Welcome to the Panopticon. Used to be a prison, now it's your home.
    5. Re:Bad font! by KiloByte · · Score: 1

      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.

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
  8. Lets use the Myan Calendar by na1led · · Score: 1

    Oh wait, it ends in 2012!

    --
    -- By all means let's be open-minded, but not so open-minded that our brains drop out.
    1. Re:Lets use the Myan Calendar by spidercoz · · Score: 4, Funny

      did your "Myans" invent the number "for"?

      --
      "I disapprove of what you say, but I will defend to the death your right to say it." - Evelyn Beatrice Hall, re Voltaire
    2. Re:Lets use the Myan Calendar by Anonymous Coward · · Score: 0

      No. They did, however, invent cats.

    3. Re:Lets use the Myan Calendar by oodaloop · · Score: 1

      I give up. What did they invent numbers for?

      Nice sig, btw.

      --
      Tic-Tac-Toe, Global Thermonuclear War, and relationships all have the same winning move.
    4. Re:Lets use the Myan Calendar by jellomizer · · Score: 1

      Or So says the Evangelical Christians. However I am not sure why they are basing their information on a Pagan Calendar.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    5. Re:Lets use the Myan Calendar by NatasRevol · · Score: 1

      And tasty they were!

      --
      There are two types of people in the world: Those who crave closure
    6. Re:Lets use the Myan Calendar by peragrin · · Score: 1

      Why not? They dont know when jesus was born so they took the winter soltise and said this is when we celebrate.

      --
      i thought once I was found, but it was only a dream.
    7. Re:Lets use the Myan Calendar by snowgirl · · Score: 2

      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...

      --
      WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
    8. Re:Lets use the Myan Calendar by Anonymous Coward · · Score: 0

      No it doesn't end, it keeps going for another few billion (134 billion, if I recall correctly) years. The information detailing the ending of the calendar is old knowledge.

  9. Our whole calendar is messed up. by Oswald+McWeany · · Score: 0

    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- which is more like Dec 21st most years on our calendar.

    So- The year should start on Dec21st.

    Then- our months are supposed to be based on cycles of the moon (Approx every 28 days)- but because there were 13 and superstitious nitwits didn't like 13 we have 12 months with varying days.

    Our current concept of a month is meaningless. 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.

    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.

    We would then have 5 or 6 days at the end- a "half week" - we would determine if it would be 5 or 6 days depending on how many days it took to reach the winter solstice since that would be the definition of new year.

    Not perfect- but based more on logic than our current system and no-silly formulas needed (other than determining the solstice)

    --
    "That's the way to do it" - Punch
    1. Re:Our whole calendar is messed up. by dmt0 · · 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.

    2. Re:Our whole calendar is messed up. by icebike · · Score: 1

      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.

      --
      Sig Battery depleted. Reverting to safe mode.
    3. Re:Our whole calendar is messed up. by Anonymous Coward · · Score: 1

      Let's just switch to stardates and be done with it!

    4. Re:Our whole calendar is messed up. by Anonymous Coward · · Score: 0

      Because Dec 21 is close to Jan 1.

    5. Re:Our whole calendar is messed up. by Oswald+McWeany · · Score: 1

      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.

      --
      "That's the way to do it" - Punch
    6. Re:Our whole calendar is messed up. by Pokermike · · Score: 1

      Let's make a week 10 days- a much more logical number.

      We could call it the metric week, and every country but the US could switch to it. Sweet.

    7. Re:Our whole calendar is messed up. by Anonymous Coward · · Score: 0

      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.

      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.

      And in early Roman times the year used to start in March, closer to the Vernal equinox, which seems like it might have had more significance than the Winter solstice. You know, the whole spring planting thing.

      And I like ten months, with 36 days each and five days of year end holiday (because nobody _really_ works at Christmas-time anyway.)

    8. Re:Our whole calendar is messed up. by jimbolauski · · Score: 1

      Do you remember the shitstorm when daylight savings time got longer, all the problems with clocks not adjusting properly and meetings being missed, and that was just an hour. Imagine a whole day being removed from the calendar every 4 years, the panic will be worse then Y2K. What about the people that were born on Feb 29, do we just say you no longer get a birthday when the calendars are updated? Will entering your birthday as Feb 29 break the system? Our system sucks but it's our system and there is no going back now.

      --
      Knowledge = Power
      P= W/t
      t=Money
      Money = Work/Knowledge so the less you know the more you make
    9. Re:Our whole calendar is messed up. by operagost · · Score: 1

      Its already been done, but I think the French ended up killing a bunch of people first.

      --

      Gamingmuseum.com: Give your 3D accelerator a rest.
    10. Re:Our whole calendar is messed up. by mooingyak · · Score: 1

      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 July and August were always there, they were simply renamed from what in English would be Quintember and Sextember.

      --
      William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
    11. Re:Our whole calendar is messed up. by icebike · · Score: 4, 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.

      --
      Sig Battery depleted. Reverting to safe mode.
    12. Re:Our whole calendar is messed up. by Guppy06 · · 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:

      • 1.) It is currently trivial to determine what day of the week successive years start on.
      • 2.) All solstices and equinoxes roughly occur the same number of days before the end of their respective months.
      • 3.) Equinoxes and solstices are treated as dates rather than instants (at this instant, it's February 29 in North America and March 1 in Asia).
      • 4.) All days are allotted to a month.
      • 5.) All days are allotted to a week.
      • 6.) Intercalary days follow a simple mathematical pattern with once-in-a-lifetime exceptions.

      In fact, 2, 4 and 6 above were deliberate design choices on the part of Julius Caesar specifically to keep things simple.

    13. Re:Our whole calendar is messed up. by mattack2 · · Score: 1

      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).

    14. Re:Our whole calendar is messed up. by Rhacman · · Score: 2

      Pff, base 10 logical? I propose we cut off everyones pinky fingers and transition everything to base-8 which is a nice power of 2. We should also probably be working on speeding up the rotation of the earth so that there are 512 days in a year. Once we do all that we can have exactly; 8 months to a year, 8 weeks to a month, and 8 days to a week.

      --
      Account -> Discussions -> Disable Sigs
    15. Re:Our whole calendar is messed up. by JazzHarper · · Score: 1

      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 the Vernal Equinox as a reference, so that it would fall on March 25th. Different dates, coinciding with various religious holidays, were used as the beginning of the year during the Middle Ages. For a while, the Anglo-Saxon custom was to use Christmas Day, which is indeed close to the Winter Solstice (and may have been influenced by earlier pagan custom), but that was changed after the Norman Conquest. In Britain and its colonies, from about 1155 until the adoption of the Gregorian Calendar in 1752, the civil calendar year began on March 25th, which coincides with the Annunciation and is close to the Vernal Equinox.

    16. Re:Our whole calendar is messed up. by Fast+Thick+Pants · · Score: 1

      Great, for the 6% of months that are 28 days. Otherwise, not so much.

      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.

    17. Re:Our whole calendar is messed up. by DragonWriter · · Score: 2

      Our whole calendar is messed up. First- Jan 1st is a poor start date.

      All start dates are equally arbitrary, so Jan. 1 is as good as anything else.

      I suspect the original pioneers intended the year to start on the Winter Solstice

      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 office), this moved more than once during the life of the Roman Republic and came to rest at January 1 in 153 B.C.

      The starting date stuck in most places using the Julian calendar (at least in common usage as to what was "New Years Day"; though lots of places moved the official starting date for the numbered year to some church holiday, and which holiday was chosen varied from place to place) and eventually became a universal norm.

      Then- our months are supposed to be based on cycles of the moon (Approx every 28 days)- but because there were 13 and superstitious nitwits didn't like 13 we have 12 months with varying days.

      Actually, no, the ancient Roman Calendar had ten months of 30 to 31 days, the months in it were never aligned to cycles of the moon, and there weren't 13 of them. It started on the vernal equinox (not the winter solistice, as you've suggested must be the case), and had a number of days added outside of any month at the end to make sure the next year started on a vernal equinox (and, since it only had 304 days in its 10 months, there were a bunch of those days.)

      A later reform brought it up to 12 months, all of which (except February) had an odd number of days (29 or 31) because odd numbers were considered lucky. February was addressed by splitting it into to pieces, each of which had an odd number of days (23 and 5), and whenever a leap month (the basic calendar was 354 days long) was added to align it with the equinoxes, the leap month was added after the first part of February and incorporated the last part of February.

      Our current concept of a month is meaningless. The whole 7 day week is rather random too- based on some out-of-date dogma that is probably mistranslated.

      Actually, the 7-day week makes sense as 1/4 of the 28-day lunar cycle; its quite likely that that shaped the creation story you are referring to rather than the other way around.

      Let's make a week 10 days- a much more logical number.

      Its a completely arbitrary number. Matching up with the median number of fingers a human has doesn't make it a "logical number".

      Not perfect- but based more on logic than our current system and no-silly formulas needed (other than determining the solstice)

      Actually, its based on no more logic than the worst of the older calendars -- its just pick some arbitrary numbers as a basis for the basic schedule based on criteria that have no fundamental utility except aesthetic appeal to the designer, and then when it doesn't match to its basic goal (aligning with the cycle of equinoxes) add however many days necessary outside the regular cycles to fix that

    18. Re:Our whole calendar is messed up. by JackPepper · · 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.

    19. Re:Our whole calendar is messed up. by Anonymous Coward · · Score: 0

      Sextember

      The sexiest month!

    20. Re:Our whole calendar is messed up. by eht · · Score: 1

      Every month has 28 days.

    21. Re:Our whole calendar is messed up. by DragonWriter · · 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.

      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 calendar wasn't pinned to the solar year, it was reached by Roman Republican practice of naming years after the consuls in office, which resulted in the year (for documentary purposes) starting on whatever date consular terms switched, which eventually got ended up being Jan. 1. This start date then stuck even after Roman consular terms became irrelevant.

      Its not like all this isn't well documented, perhaps you should bother to read up on what is known about a topic before trumpeting assumptions as likely-to-be-true that are based on nothing more than your speculation about dates that happen to be near each other.

    22. Re:Our whole calendar is messed up. by JazzHarper · · Score: 2

      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).

    23. Re:Our whole calendar is messed up. by Fast+Thick+Pants · · Score: 1

      Not in my new scheme; the short month would be down to 13, or 14 on leap years. I don't want February to be short though -- it's been short long enough. Calculations would be a lot simpler all around if the *last* month were the short one.

      That's right -- a war on Chistmas!

    24. Re:Our whole calendar is messed up. by VortexCortex · · Score: 0

      Let's just switch to stardates and be done with it!

      Stardates are horible. The official way to create a stardate for an episode was to just pull some seemingly random numbers out of you mind, and affix incrementing fractional components throughout the episode.

      There exists one event that everyone can agree upon: The Big Bang. Now, even if you don't believe that's what started everything, no matter where (or when) you are you can infer the time of the origin of the Universe using the big-bang concept from the observable cosmic background radiation. So, we use that as a universal starting point, literally.

      Now, no two planetary systems have ever agreed upon a standard measure of time, this is because their years and days vary wildly. So, instead, each system is assigned a Pan-Universal Chronographical Constant that's equivalent to the number of the plank lengths in one of their home planet's orbits. Here, on Earth, I use PUTY as the time units (Pan Universal Terran Years). Right now the time is:
      13,733,143,604.163016574ty -- The number of Earth orbits down to a fraction of a second since the Big Bang occured, if Earth could have existed since the universal origin, and always orbited at its current speed. The whole number increments once a year. The decimals can be carried out as far as you like to get more precise measures if you like.

      Fortunately all species have their own languages, and our universal translator is implemented by a computer which can easily multiply PUTY by Earth's PUCC, then divide by any other planetary system's PUCC to present a unified concept of time during speech. Those learning a new language must also learn to use the native measures as well as the words, it's not that big of a deal, except to races of machine-intelligences.

      The decoupling of local time to universal time via chronographical constants is an example of Wheeler's law: "All problems ... can be solved by another level of indirection". Originally applied to computer science, it also applies to everything else: diplomacy (mediators), chronography, biology, etc.

      Earth's PUCC is approximately 1.70125277e-36, which is roughly equivalent to: 365.242190419 * 24 * 60 * 60 * 5.39106e-44

    25. Re:Our whole calendar is messed up. by Anonymous Coward · · Score: 0

      Stardates are horible. The official way to create a stardate for an episode was to just pull some seemingly random numbers out of you mind, and affix incrementing fractional components throughout the episode.

      Julian and Gregorian dates were set by the seasons.

      Star Trek stardates are not random. They, too, are computable based on seasons. TV seasons, but seasons nonetheless.

    26. Re:Our whole calendar is messed up. by johnnysaucepn · · Score: 1

      A month is 1/12th of a solar cycle, a week is 1/4 of a lunar cycle.

    27. Re:Our whole calendar is messed up. by camperdave · · Score: 3, Interesting

      I like the Shire Reckoning calendar better. Twelve months of 30 days, with 5 days in the middle of summer that are not assigned to any month. In leap year, there are six. Being in the middle of the summer (and being of hobbit origin), these days are used for parties and feast days.

      --
      When our name is on the back of your car, we're behind you all the way!
    28. Re:Our whole calendar is messed up. by Amazing+Proton+Boy · · Score: 1

      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.

    29. Re:Our whole calendar is messed up. by Anonymous Coward · · Score: 0

      I think he meant median.

      Do you propose that half of humans have less than ten, or that half have more than ten? Or does the spelling similarity of "mean" and "median" confuse your mind?

    30. Re:Our whole calendar is messed up. by Anonymous Coward · · Score: 0

      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.

      Sounds like a perfect job creating, economy boosting idea to me! Certainly beats moving piles of rocks.

    31. Re:Our whole calendar is messed up. by Darinbob · · Score: 2

      We should just have star dates.

    32. Re:Our whole calendar is messed up. by snowgirl · · Score: 1

      (the original word in Genesis translated as "day" was more accurately "a period of time" although it was often "day" but not necessarily

      Yes, and so Yom Kippur is the "period of time of atonement", rather than the "day" of atonement?

      Plus, the first mention of "yom" in the text is "God called the light 'yom' and the darkness he called Night. And there was evening and there was morning, the first 'yom'." ... it's kind of hard to argue against a non-literal interpretation of "yom" as "day", when clearly the first day was a single cycle of evening and morning.

      --
      WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
    33. Re:Our whole calendar is messed up. by AK+Marc · · Score: 1

      Ever wonder why Feb was the catch-all (last) month of the calendar? Because they started the calendar with March before. That's the first month good for warring, so it starts the year. Re-aligning the start to the month start closest to the solstice wasn't until later. Yes, starting the year on the day after the solstice and the year end on the solstice would be self-correcting, but almost incalculable. People prefer consistency to accuracy.

    34. Re:Our whole calendar is messed up. by srjh · · Score: 1

      Actually, both the median and the mode would be 10 unless I'm drastically under/overestimating the incidence of polydactyly and missing digits.

      It's the median that is closest to the definition you're asking about, however if less than half the population has 10 digits, the median is exactly ten.

    35. Re:Our whole calendar is messed up. by srjh · · Score: 1

      I think part of that comment must have disappeared due to the angled brackets.

      I mean if less than half the population has fewer than 10 digits and less than half the population has more than 10 digits, the median is exactly ten.

    36. Re:Our whole calendar is messed up. by petman · · Score: 1

      Oh, come on! Why don't you go open another tab in your browser there and google for a lunar calendar? You'll see that a lunar month has between 29 to 30 days. A full lunar year cycle would have about 354 days, give or take a day or two.

    37. Re:Our whole calendar is messed up. by petman · · Score: 1

      Let me clarify - that 354 days refer to a lunar year with 12 lunar months. A year with 13 months would have approx. 384 days.

    38. Re:Our whole calendar is messed up. by Anonymous Coward · · Score: 0

      I have been ranting about a 13 month year to my coworkers for about a year now.

      Is that a 12 month year or a 13 month year?

    39. Re:Our whole calendar is messed up. by Anonymous Coward · · Score: 0

      Now, no two planetary systems have ever agreed upon a standard measure of time, this is because their years and days vary wildly. So, instead, each system is assigned a Pan-Universal Chronographical Constant that's equivalent to the number of the plank lengths in one of their home planet's orbits. Here, on Earth, I use PUTY as the time units (Pan Universal Terran Years). Right now the time is: 13,733,143,604.163016574ty -- The number of Earth orbits down to a fraction of a second since the Big Bang occured, if Earth could have existed since the universal origin, and always orbited at its current speed. The whole number increments once a year. The decimals can be carried out as far as you like to get more precise measures if you like.

      In other words, the Pan-Universal Chronographical Constant isn't a constant...

    40. Re:Our whole calendar is messed up. by sFurbo · · Score: 1

      Then- our months are supposed to be based on cycles of the moon (Approx every 28 days)- but because there were 13 and superstitious nitwits didn't like 13 we have 12 months with varying days.

      The time between two new moons is approximately 29.5 days. 28 is only used because it is a multiple of 7 (the number of greco-roman planets), and it divides the lunation into nice periods between new, half, full and half.

    41. Re:Our whole calendar is messed up. by Oswald+McWeany · · Score: 1

      oooh an internet hardman with his panties in a wad. I'm scared.

      January 1st has no measurable quantity- there it is for all purposes unreliable as a starting point for a year with no significant meaning. Setting the start of the year to an equinox or a solstice would be fine with me. January 1st is just silly- it has no meaning. It is just one factor amongst many that is arbitrary and meaningless about our calendar.

      Personally, I think a solstice would make more sense for start of a year- but following the roman example of the equinox with the agricultural reasoning would be better than Jan 1.

      --
      "That's the way to do it" - Punch
    42. Re:Our whole calendar is messed up. by Anonymous Coward · · Score: 0

      Summer in Northern Hemisphere is Winter in Southern Hemisphere. So some people will have 5-6 more days in cold Winter. If people in Southern Hemisphere are using different calendar, they do not align with North.

    43. Re:Our whole calendar is messed up. by Anonymous Coward · · Score: 0

      OK, while we're on the subject, let's reform the calendar once more and get it right.

      First, there's absolutely no reason to have a runt month like February. EVERY MONTH shall have 30 or 31 days EVERY YEAR.

      Second, to fix the divisibility issues, we shall shorten the leap days to 23 hours 49 minutes and 17.663 seconds (or whatever the correct length is to account for the not-quite-1/4 extra day per year effect). That way EVERY FOURTH YEAR IS A LEAP YEAR. NO EXCEPTIONS.

      Third, to minimize disruptions to work schedules and reruns of Leave It To Beaver, leap days, when they occur, shall be on December 31. And it shall be declared a holiday in all jurisdictions. Who's going to object to an extra day to get drunk and party, even if it's not quite 24 hours?

      (Non-leap years shall end on Dec. 30.)

    44. Re:Our whole calendar is messed up. by Guppy06 · · Score: 1

      First, there's absolutely no reason to have a runt month like February.

      365 is the product of two prime numbers. You can either have 5 divisions of 73 days each, or 73 divisions of 5 days each. Otherwise, there is no nice, neat way to divide up the calendar.

      EVERY MONTH shall have 30 or 31 days EVERY YEAR.

      That breaks the predictability of the seasons. As they are now, both solstices and one equinox are at roughly 11 days before the end of their respective months. The odd man out is September, and that can't be fixed while abiding by your "30 or 31 only" declaration.

      Keep in mind that the seasons all have different lengths, owing to the variation in the earth's velocity (faster near perihelion, etc.).

      Second, to fix the divisibility issues, we shall shorten the leap days to 23 hours 49 minutes and 17.663 seconds (or whatever the correct length is to account for the not-quite-1/4 extra day per year effect).

      First off, that breaks the mean solar day. The entire point of a calendar is to count integer numbers of mean solar days.

      Second, the "correct length" varies from year to year, and is typically only known after the fact. In fact, both the mean solar day and the mean tropical year are inconstant and vary wholly independently from each other.

      Third, the length of your intercalary day can't be remembered by the average high school graduate. The current system can be reproduced by the average elementary school student to 97% accuracy. Exceptions are once in a lifetime, and not even in our lifetime.

      Keep in mind that the Gregorian calendar is accurate for its intended purposes for several more millennia at least.

      Third, to minimize disruptions to work schedules and reruns of Leave It To Beaver, leap days, when they occur, shall be on December 31. And it shall be declared a holiday in all jurisdictions.

      Good luck with that. Not all governments use the Gregorian Calendar for all purposes as it is.

  10. Length of year, day, etc. by AliasMarlowe · · Score: 2

    A year is not even exactly 365.2422 days long (if we could actually agree how long a "day" is).

    --
    Those who can make you believe absurdities can make you commit atrocities. - Voltaire
    1. Re:Length of year, day, etc. by WebManWalking · · Score: 2

      The 3/1000 difference from .2425 to .2422 results in a Y30K problem. After 30,000 AD, we can relax for a while.

    2. Re:Length of year, day, etc. by tompaulco · · Score: 2

      The 3/1000 difference from .2425 to .2422 results in a Y30K problem. After 30,000 AD, we can relax for a while.
      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

      --
      If you are not allowed to question your government then the government has answered your question.
    3. Re:Length of year, day, etc. by Anonymous Coward · · Score: 1

      That would be 3/10000, not 3/1000. FTFY

    4. Re:Length of year, day, etc. by mwvdlee · · Score: 2

      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.

      --
      Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
    5. Re:Length of year, day, etc. by hutsell · · Score: 1

      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.

      The length of a day does create the number of days in a year. However, the total amount of days in the year will never be equal to exactly one year--there will always be a partial day at the end of one year, regardless of each day's length. The reason is geometrical due to the planet orbiting the star--it's not a rotational speed issue.

      Imagine the planet stopped in its orbit, but rotating; the point on the Earth directly pointing at the Sun returns to its original position, making it be one day.

      Now imagine again the same scenario, this time moving in orbit around the Sun; after completing exactly one rotational day as previously mentioned, it has moved in orbit just a little further--now it needs to play catchup by rotating just a little further (it's about a minute) to make the Sun appear to be at its original position so that it'll appear to us to be one day.

      The only time when the number of days does equal exactly one year, is when the rotational day and the orbital year are the same--the planet Mercury and the Earth's Moon being a couple of examples. So, if I understood your explanation, then the math is unnecessary. :)

      .

      --
      Yesterday's Weirdness is Tomorrow's Reason Why
  11. Knowing the rules (and not just for leap day) by RyoShin · · Score: 4, 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.

    1. Re:Knowing the rules (and not just for leap day) by u38cg · · Score: 1
      And, of course you compensated for the missing days between the Gregorian and Julian calendars?

      Date classes are indeed a wonderful (if cruel) introduction to real world programming.

      --
      [FUCK BETA]
  12. Wait, what? by Jorl17 · · Score: 4, Funny
    --
    Have you heard about SoylentNews?
    1. Re:Wait, what? by pz · · Score: 2

      Today is Feb 29, a leap day, that's why it's relevant. Tomorrow, it will be far less so.

      --

      Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
    2. Re:Wait, what? by Anonymous Coward · · Score: 0

      Well, if that wasn't the biggest 'WHOOSH' I've ever heard.

  13. In Soviet Russia... by THE_WELL_HUNG_OYSTER · · Score: 1

    In Soviet Russia, leap year comes every time Politburo says it comes.

    1. Re:In Soviet Russia... by spidercoz · · Score: 4, Funny
      that was really forced, and you're doing it wrong

      e.g.; "In Soviet Russia, year leaps you! Ha ha ha." (there's no way to spell Yakov's laugh)

      --
      "I disapprove of what you say, but I will defend to the death your right to say it." - Evelyn Beatrice Hall, re Voltaire
    2. Re:In Soviet Russia... by Culture20 · · Score: 1

      (there's no way to spell Yakov's laugh)

      Sure there is:
      !ah ah aH

  14. A video with visualisations by Kenosti · · Score: 3, Informative

    I much prefer the explanation in this video: http://www.youtube.com/watch?feature=player_embedded&v=xX96xng7sAE

    1. Re:A video with visualisations by Anonymous Coward · · Score: 0

      I much prefer the explanation in this video: http://www.youtube.com/watch?feature=player_embedded&v=xX96xng7sAE

      Very nice explanation indeed - although the narrator should lay off the Red Bull.

  15. Four days too late! by Guppy06 · · Score: 4, 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.

    1. Re:Four days too late! by Guppy06 · · Score: 1

      Er, five days too late.

      Fuck my non-life.

  16. leap days make ood codeing bugs show up some times by Joe_Dragon · · Score: 2
  17. Who are we kidding? The real reason for leap days: by EmagGeek · · Score: 2

    To give first-time programming students a fun and interesting homework assignment.

  18. We're all going to die... by docilespelunker · · Score: 1

    Hopefully no time soon, but almost certainly before 2100, when the next leap year doesn't happen. If due to lots of exercise, few pizzas and a whole bunch of luck we do survive that long, then we'll all be too dotty to know what day it is anyway. Glad this is sorted. All we have to know is that it happens every 4 years and will do for the entire rest of ever, so long as we care. Lets get coding and hardwire in a leap year to make the 2100 bug!

    1. Re:We're all going to die... by sconeu · · Score: 1

      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.

      --
      General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
  19. WTH? by geekoid · · Score: 1

    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.

    --
    The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
    1. Re:WTH? by JTsyo · · Score: 1

      We all just need to add to our post count.

  20. Totally agree. by Anonymous Coward · · Score: 0

    I wrote a leap-day calculator in PIC16 ASM about a decade ago as part of a weekday-on-a-given-date calculation. I don't think it was any more than 20 op-codes with one of the most limited ISA's that exists.

    It's not complicated at all. Programmers only make mistakes because they don't do their research as to what exactly they're trying to calculate.

    1. Re:Totally agree. by jc42 · · Score: 5, Interesting
      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."

      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. ;-)

      --
      Those who do study history are doomed to stand helplessly by while everyone else repeats it.
    2. Re:Totally agree. by camperdave · · Score: 2

      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!

      --
      When our name is on the back of your car, we're behind you all the way!
    3. Re:Totally agree. by giorgist · · Score: 1

      No mention of leap seconds in your Latin text unless it was lost in translation

      http://en.wikipedia.org/wiki/Leap_second

    4. Re:Totally agree. by jc42 · · Score: 1

      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, 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 comes up. "If the bible [or the pope ;-] truly tells us all we need to know about the world, where is the commandment on how to implement leap seconds? Inquiring believers want to know ..."

      After all, if God hadn't wanted us to use leap seconds, He would clearly have set things up so that the day, month and year are all integer multiples of the next-smallest unit. And they'd stay that way, not wavering all over the place on the millisecond level like our world's rotation obviously does. So He must have intended that we come to terms with all the incommensurabilities in the solar system's rotations and orbits. Where is this documented in the canon?

      --
      Those who do study history are doomed to stand helplessly by while everyone else repeats it.
    5. Re:Totally agree. by adamofgreyskull · · Score: 1
      Wow, he completely accurately described the system of leap-years! In Latin! He must have been a genius! Of course, if that's the origin of the system, how can it be wrong? :) It's like lauding the authors of the original SMTP RFC because it completely accurately described the SMTP standard as described by that RFC! Holy Circular Logic Batman!

      Oh, and before we congratulate the Pope's astronomer too much, I'll quote the FA:

      ...
      Of course, the calendar’s still not completely accurate at this point, because now we’re ahead again. We’ve added a day, when we should have added only 0.8762 days, so we’re ahead now by

      1 – 0.8762 days = 0.1238 days.

      Funny thing is, no one worries about that. There is no official rule for leap days with cycles bigger than 400 years. I think this is extremely ironic, because the amount we are off every 400 years is almost exactly 1/8th of a day! So after 3200 years, we’ve had 8 of those 400 year cycles, so we’re ahead by

      8 x 0.1238 days = 0.9904 days.

      Maybe we should go a little easy on him since he did have to write in Latin and didn't have access to sophisticated measuring tools. Though, maybe if they'd spent a little less time persecuting others, designing silly hats and talking to an invisible man they might have done.

    6. Re:Totally agree. by petman · · Score: 1
      Google Translate really cleared it up for me:

      Then, lest the day before the Calends of April 12 from the equinox recede in the future, we establish that every fourth leap year (as is the custom) ought to be continued, in addition to, in the hundred years, who, although he had always bissextile they have been, such as we wish that year 1600, after him, which from that time, however, they are not all in the hundred and bissextile obtain, but in each four hundred years, the first, and those who have no bissextile in the hundred and three, the fourth, however, each one in a hundred is bissextile, so that the year 1700, 1800, 1900 bissextile they are not. In the year of 2000, however, in the manner usual intercalation day of the leap day, February 29 the day of the continent, the same order of intercalations of intermittent leap day in each four hundred years, preserved in perpetuity.

    7. Re:Totally agree. by Anonymous Coward · · Score: 0

      The Bad Astronomer is actually wrong to project the calendar out to 3200 years in this way. He is assuming that the rotation and orbital parameters of the Earth will remain the same, but in fact the Earth's rotation tends to slow by around 2 milliseconds per century, due to tidal interactions with the Moon. Over a period of 3200 years, the accumulated effect on the calendar dates of the equinoxes will be about 0.4 days, which is a significant effect that the Bad Astronomer has failed to account for.

      Furthermore, the actual future slowing of the Earth's rotation cannot be predicted with any great certainty. This is partly due to the difficulties in making sufficiently accurate measurements of past slowing, and partly due to the influence of the mass distribution of the Earth. I.e., ice caps may shrink (or grow) and the ocean may rise (or fall). So really the Gregorian calendar is the best that we can do at this point anyway.

    8. Re:Totally agree. by Anonymous Coward · · Score: 0

      All the dates in the Bible use a lunisolar calendar.

  21. Programming Professors Pay Attention! by _0x783czar · · Score: 1

    The answer to every programming Professor's favorite Intro. to Programming project assignment has now been leaked on the web! What will become of all the students who can now look up the formula to that mind-bending programming challenge of making a calendar application.

    --
    ~theCzar
  22. Re:Just make the second a little longer by arth1 · · Score: 1

    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.

  23. A modest proposal by StikyPad · · Score: 1

    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!

    1. Re:A modest proposal by Anonymous Coward · · Score: 0

      A simpler solution which doesn't harm the environment nearly as much, costs less money, gets everyone into shape, and takes care of the obligatory XKCD reference for this thread: Angular Momentum

  24. Re:leap days make ood codeing bugs show up some ti by Anonymous Coward · · Score: 0

    odd spelling too

  25. drop astronomy for Planck units by peter303 · · Score: 1

    Chose an aribitrary starting time, say the origin of this universe about 8 x 10^60 Plank units ago.

    1. Re:drop astronomy for Planck units by Anonymous Coward · · Score: 0
      I did once. I worked out the number of days since the atom was first split (can't remember when, exactly) and then split it into "decadays". This gave me 'Stardate: 1124.5" or something like that. Filled in many a boring maths lesson back at school.

      And yes, I was into Star Trek at the time. Why do you ask?

  26. Re:Just make the second a little longer by alva_edison · · Score: 1

    Where do you live that midday occurs at noon. The only guarantee is that midday and noon are within two hours of each other. This is due to timezones (roughly an hour wide) and daylight saving (shifting things off by an hour).

    --
    He effected a bored affect.
  27. Re:Just make the second a little longer by alva_edison · · Score: 1

    Although, you're talking about shift, which over time would put it further out of sync than it already is. I view that as a possibly good thing, then we can get rid of the timezones, and everyone uses GMT. That also means no more DST.

    --
    He effected a bored affect.
  28. Misidentifying the source of the problem by DragonWriter · · Score: 1

    leap days make ood codeing bugs show up some times

    When code does not correctly model the problem domain, the error isn't with the domain.

  29. Revised Julian Calendar by uigrad_2000 · · Score: 4, 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

    Those who follow the Revised Julian Calendar 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.

    --
    Free unix account: freeshell.org
  30. Re:Oblig. xkcd by maxwell+demon · · Score: 0

    Oh, wait. I'm just an unoriginal fuckass. Might as well mod me into the stratosphere, though.

    Well, an "oblig. xkcd" without a link or even an indication which one is meant, that is new as far as I can tell.

    --
    The Tao of math: The numbers you can count are not the real numbers.
  31. I think you're doing it wrong by Zinho · · Score: 3, 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.

    --
    "Space Exploration is not endless circles in low earth orbit." -Buzz Aldrin
    1. Re:I think you're doing it wrong by Anonymous Coward · · Score: 0

      (UTC isn't affected by DST like GMT is)

      Repeat after me: When England enters DST, they are in BST (British Summer Time). It is NOT still called GMT!!!

    2. Re:I think you're doing it wrong by Anonymous Coward · · Score: 0

      UTC isn't affected by DST like GMT is

      GMT is affected by DST? Citation needed.

    3. Re:I think you're doing it wrong by Anonymous Coward · · Score: 1

      The DST translation should be done for display purposes only

      Too much business logic depends on local time. Think about traffic flows, electricity demand, bandwidth usage, etc. It doesn't matter what the fuck time it is in Greenwich. These get modeled, regressed, and allocated against local time.

      It's not just a "display issue"

    4. Re:I think you're doing it wrong by Hognoxious · · Score: 1

      These get modeled, regressed, and allocated against local time.

      And they get mdeled[sic], regressed and allocated wrongly because programmers write their own half-assed date & time routines.

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    5. Re:I think you're doing it wrong by mwvdlee · · Score: 1

      I wouldn't like to be responsible for the massacre caused by a crossing where the traffic lights are in two different timezones and they both communicate with their own timezones.
      Any business logic that depends on local time being reliable, is unreliable by design simply because timezones are unreliable (they change due to political/social reasons).

      --
      Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
    6. Re:I think you're doing it wrong by petermgreen · · Score: 1

      Now suppose that traffic lights are supposed to use different rules in rush hour which is defined in terms of working hours which in turn are defined in terms of local time. Add that to the fact that it is not possible to reliablly convert future times between universal time and local time and you might understand why time issues are so easy to fuck up. Using entirely local time is not a soloution and neither is using entirely universal time. Any app that works with time and wants things to work properly in line with user expectation has to understand timezones and DST.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    7. Re:I think you're doing it wrong by petermgreen · · Score: 1

      You seem to have misunderstood the point the GP was making.

      No he hasn't misunderstood it at all.

      Those problems only become issues for people working with heterogeneous data sets

      No they also become a problem for any system that deals with future events scheduled by people. Like it or not the real world schedules things on local time and like it or not it is not possible to reliablly convert future times between local time and universal time because the mapping rules can be changed at any time. Sometimes with very little notice.

      Consider a user sets a repeating alarm for 7AM local time on every weekday. That user damn well expects an alarm at 7AM local time even if the mapping between local time and universal time has changed in the meantime (either due to a DST jump or a rule change).

      Consider a user schedules a meeting for 9AM local time on a given day. The users damn well expect that meeting to stay scheulded for 9AM local time even if the mapping rules change between the meeting being scheduled and the meeting happening.

      Things get even worse if you have users from different timezones. Now you have to store which local time an event is scheduled in. Then when an update to the timezone rules come in you have to

      1: find any users who are associated with events in foreign timezones.
      2: Recompute the translation from the event's local time to the user's local time.
      3: See if that translation has changed, if so generate a warning for the user and re-run any conflict checking that your system does.

      Oh and you can't rely on end users computers to reliablly convert between universal time and a given timezone even for times in the past firstly because they may not be up to date and secondly because windows doesn't keep data on historical mapping rules.

      This is tricky to get right and the results of getting it wrong only tend to show up occasionally especially for users in the west (whose governments seem to have some understanding of the value of stable timezone rules) so a great many systems get it wrong causing all sorts of fun when a rule change comes in.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    8. Re:I think you're doing it wrong by mwvdlee · · Score: 1

      If it is not possible to reliably convert future times between UTC and local time, image how much worse it would be if they both communicated with their own local time and each had to convert the others' local time to their own local time. Apart from having to do TWO conversions instead of one, you're introducing all kinds of timing issues. As a general rule, I try to avoid datatypes that change meaning depending on when you're working with it. You can't always leave timezones out of your datastorage, but when you can, you should.

      --
      Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
    9. Re:I think you're doing it wrong by Zinho · · Score: 1

      Those problems only become issues for people working with heterogeneous data sets

      No they also become a problem for any system that deals with future events scheduled by people. Like it or not the real world schedules things on local time and like it or not it is not possible to reliablly convert future times between local time and universal time because the mapping rules can be changed at any time. . .

      Consider a user sets a repeating alarm for 7AM local time on every weekday. That user damn well expects an alarm at 7AM local time even if the mapping between local time and universal time has changed in the meantime (either due to a DST jump or a rule change).

      You make a good point here. Any alarm clock that wakes me up at the wrong hour because of a DST change is broken. (see footnote)

      Consider a user schedules a meeting for 9AM local time on a given day. The users damn well expect that meeting to stay scheulded for 9AM local time even if the mapping rules change between the meeting being scheduled and the meeting happening.

      Things get even worse if you have users from different timezones.

      I agree again, any calendaring program that doesn't adjust your meeting time for DST is broken. I feel this pain; I work for a company with offices in the U.S. and Norway, and the mismatch between our DST schedule and theirs is a cause of confusion 4 times a year.

      Now you have to store which local time an event is scheduled in. Then when an update to the timezone rules come in you have to

      1: find any users who are associated with events in foreign timezones.
      2: Recompute the translation from the event's local time to the user's local time.
      3: See if that translation has changed, if so generate a warning for the user and re-run any conflict checking that your system does.

      Sounds like a good plan. I don't see how storing the time as UTC will cause a problem if you're keeping the primary locale and a DST flag as part of the record. The issues you're addressing here will exist regardless of whether the time is stored in UTC or local time, and I can't imagine that having the system store my appointments in US local time and my co-workers appointments in Norwegian local time would be any better; on the contrary, the routines would only get more complex when dealing with mismatched time records. I'd modify the procedure a bit, though:

      1: get notified of time zone change
      2: find all appointments whose primary locale is in the affected time zone
      3: adjust UTC time record to match correct, adjusted meeting time in the primary locale according to the new rule
      4: alert attendees for the affected meeting that the time has changed; their client stores the new UTC time, and continues to display it correctly for their local time

      My procedure has more steps than yours, but can be easily translated to fast-running database queries. Why are you worrying about future, hypothetical changes to time zone rules when you've already laid out the procedure for adjusting to changes? Store future dates according to the best current information, and adjust as needed when the change comes. Requiring more than that is expecting either the computer or the programmer to be psychic.

      Oh and you can't rely on end users computers to reliablly convert between universal time and a given timezone even for times in the past firstly because they may not be up to date and secondly because windows doesn't keep data on historical mapping rules. (emphasis added)

      I think this is where we disagree, really. First, anyone coordinating global appointment schedules on their workstation is doing it VERY wrong; that sort of thing should be on a central server (like Exchange). The periodic sync each client does to the central database should also push new time zone rules as needed; the client should never be out of date. Second,

      --
      "Space Exploration is not endless circles in low earth orbit." -Buzz Aldrin
    10. Re:I think you're doing it wrong by RockDoctor · · Score: 1

      Things get even worse if you have users from different timezones.

      Where did the "if" come from? In my country, a minimal business case is almost certainly going to have to deal with people from this country and on the continental mainland, and so deal with a minimum of two time zones and four DST shifts per year. (There's a real possibility of Scotland having to schism from the UK in terms of time zoning if Westminster goes ahead with it's proposals for double-winter time, leaving us with sunrise at 10:00 local time in mid-winter, and a safe expectation of dozens of deaths per year. Not likely to be accepted, so even if England moves onto CET, we're likely to stay on a more westerly time zone. What Wales chooses to do in that case will be interesting to see.).
      If you're in America, then you've got 3 or 4 different time zones to contend with, if not in your immediate users, then in your suppliers, customers, or regulatory agencies. (I'm almost inclined to ask if Alaska extends over several time zones? It should do, considering it's latitude and size, but would make for even more confusion.) In my day to day work, I'm typically working across 4 time zones, and have worked across 10 time zones. But our pet programmers never expected that and have to be repeatedly reminded that the company's target is "World Domination, without undue delay," so we're still contending with incoherent and and inconsistent handling of date-time data.

      Oh, I'm sorry ; I just realised that you're programming Quechua spelling-checkers, for the Chilean and Peruvian market. So, for you, multiple time zones really aren't an issue, like they would be for any more widely-spread language (or country).

      --
      Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"
    11. Re:I think you're doing it wrong by petermgreen · · Score: 1

      alert attendees for the affected meeting that the time has changed; their client stores the new UTC time, and continues to display it correctly for their local time

      It's not quite as simpel as alerting all attendees for the "affected meeting". You want to alert atendees for which the time has changed from their perspective. If the rules for an atendee's timezone change then a meetings time can change from their perspective without the UTC time of the meeting changing. Likewise if the rules change in the same way for the atendee's timezone and the meeting's timezone the meeting may not move from the atendees perspective even though it moved in UTC time.

      But yeah generally I agree there is nothing wrong with keeping UTC times of future events in the DB for comparison purposes. The problems come when you treat them as the primary data item rather than as a generated data item whose value may change when a rule change comes through.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
  32. This isn't hard by Anonymous Coward · · Score: 0

    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.

    No... no, there's not:

    If the year is divisible by 4, then it’s a leap year, UNLESS

    it’s also divisible by 100, then it’s not a leap year, UNLESS FURTHER

    the year is divisible by 400, then it is a leap year.

    Done.

  33. leap years *NOT* simply divisible by 4 by Anonymous Coward · · Score: 0

    If ((year modulo 4 is 0) and (year modulo 100 is not 0)) or (year modulo 400 is 0) Then
        leapYear = true
      Else
        leapYear = false
      End if

    http://www.JetCityOrange.com/leap-year/

  34. Easy to read by webnut77 · · Score: 1

    if (($yr % 400) == 0) $leapYear = true;
    else if (($yr % 100) == 0) $leapYear = false;
    else if (($yr %4) == 0) $leapYear = true;
    else $leapYear = false;

    1. Re:Easy to read by Anonymous Coward · · Score: 0

      It's perl! It's meant to be unreadable!

      It should be something like:

      $leapYear=(($year%4==0)and($year%100!=0))or($year%400==0);

      Actually the variables should probably be called $l and $y and maybe I should have used && and || instead to make it even more unreadable.

  35. Old News by KramberryKoncerto · · Score: 1

    So we're going to see this every four years? Except every hundred years? Except every four hundred years?

  36. That's all well and good by Deliveranc3 · · Score: 1

    But how come our libraries aren't smarter about it.

    Converting to a datetime shouldn't be so difficult. Neither should handling month short forms (Sept. I'm looking at you!) obviously we should be moving to metric time. (Five fingers FTW!).

    Even 20 years ago November and December were winter, now it doesn't really get cold enough for snow until late December (in Canada)...

    Screw the Romans, and screw the issues with daylight savings, how about some proper month representation.

  37. TFA without all the useless fluff by wye43 · · Score: 1

    365.24219878125

    That's all, really.

  38. Pedantry by Ed+Avis · · Score: 1

    If a leap year is a year that contains one extra day, then surely a leap day is a day that contains one extra second, as happens from time to time to adjust UTC for the earth's rotation. (The extra second is always added just before midnight.) But then, people call that a 'leap second', even though it is exactly the same length as any other second...

    --
    -- Ed Avis ed@membled.com
  39. Excel formula by docilespelunker · · Score: 1

    Naturally I couldn’t let this bit of maths go. I’ve made an overly complicated spreadsheet that generates correctly formatted wall planners. Initially I was happy that this nonsense happens every 4 years and will do for the useful period of the wall planner generator. Then I drank too much coffee and added the correction anyway. Assuming cell A1 contains the year of interest, this formula gives the number of days in February: =IF(MOD(A1,4)=0,IF(MOD(A1,100)=0,IF(MOD(A1,1000)=0,29,28),29),28)

    1. Re:Excel formula by u38cg · · Score: 1

      Surely it would be easier to do 1 Mar - 1 Feb.

      --
      [FUCK BETA]
  40. Wow by jopet · · Score: 1

    Basic primary school knowledge in the discovery magazine and slashdot.

  41. Re:Number four invented for Certain by Anonymous Coward · · Score: 0

    THIS SHOULD CLEAR IT UP:

    “Of course, up until recently there was no such thing as number four.” Karnov says.

    “Is that a euphemism?”

    “No. I mean that the number sequence went one, two, three, five, six sevenAnd so on.”

    “So there was no number four?”

    “Not at all. It has been proven that a child named Boba Fett invented the number four. -And very recently too.”

    Niall can’t believe he is hearing this. “But I remember the number four from my childhood!”

    Rojic explains. “You say you do, but with things this fundamental, there is a group unconsciousness thing going on, and a racial memory block that prevents you from remembering the absence of the thing that now you can recall. -Whereas previously you didn’t, nay- couldn’t possibly. There was nothing to remember to forget and re-remember now that you have forgotten.”

    “Thanks Rojic, you actually help more by not helping.”

    Rojic flits off. “I’m off to repressurise the emergency re-pressurisation cylinders.”

    “That’s easy for him to say.”

    Niall and Karnov glower at one another.

    Niall finally says. “When you're arguing with a fool, make sure he isn't doing the same thing.”

    Karnov has the last laugh. “I think that actually says more about you than me.”

    They both think about this, all the while trying not to prove one another wrong or right.

    Finally, Niall says, “What did Rojic say he was going to do?”

    “Something about re-melting the sausages.”

    “That’s what I thought.”

    Rojic shouts back through the hatch. “Not melting, smelting.”

    In unison Niall and Karnov call back. “I’m smelting!”

    TO READ THE REST, SEE:
        http://homepage.ntlworld.com/anthonyandanna/Starwars/1.25.html

  42. Re:Number four invented for Certain by Anonymous Coward · · Score: 0

    So it is true! A Young Boba Fett invented the number four in his early childhood - that'd be around 25 BBY then.

    If you thought Our calendar was crocked, think about the star wars one: In which years are recorded up to an event in the future which has not yet happened! If you added a few leap years between the clone wars and the Battle of Yavin, you'd miss it by several days! -D'oh!

  43. Naa: base 13 by Zoxed · · Score: 1

    I vote for growing 3 extra fingers. Then we can use Base 13. The jokes are better.

  44. Re:leap days make ood codeing bugs show up some ti by Zoxed · · Score: 1

    Or it was a Dr Who reference ?

  45. it's real easy by Anonymous Coward · · Score: 0

    no math required. i wake up, and turn on the morning news. i know what day it is and the temperature. sweet!

  46. "Every for [sic] years"? by Anonymous Coward · · Score: 0

    Is there an editor in the room?

  47. A Good Interview Question by Anonymous Coward · · Score: 0

    Once upon a time, my favorite interview question for prospective programmers was "How long does a year last?" This was around 2000, so leap year trivia was hot. The answer I wanted was for the candidate to break down the leap year rules and come up with 365.2422 or thereabouts.

    It was depressing how many interviewees didn't even understand that a year is the time it takes the Earth to orbit the sun. Many confused the Earth's orbit and the Earth's rotation. Yes, some thought it took 24 hours to orbit the sun.

  48. Leap Years; A Modest Proposal by Christopher_T. · · Score: 1

    Can't we just change the orbit of the Earth so one year = 360 days?

  49. Not NEWS!!! by Anonymous Coward · · Score: 0

    The leap year calculation is a trivial one liner. I did this in BASIC in 1980 when learning programming.