• (cs)

    So the WTF is that the developer though that you can't use Unix Epoch on a windows server?

    Also Frist

  • me (unregistered)

    scond

    not spam

  • Nagesh (unregistered)

    This aproach is prefered. Simpler to be converting to C for linux app (much quiker performing) or any system without suport library function. Time function is wel-defined already: why convert to langage-specific fuctions for no benefit?

  • Erlando (unregistered)

    It doesn't account for leap years correctly...

  • noname (unregistered)

    It does account for leap years: (((year - 1970)/4) * DAY)

    But because 2000 is not a leap year the generated date is one day off. As long as both dates are between 1.1.2001 and 31.12.2099 no one will notice.

  • emaN ruoY (unregistered)

    This comment was designed to be Frist.

  • (cs) in reply to Erlando
    Erlando:
    It doesn't account for leap years correctly...
    In fact, it doesn't even come close. It will return the same value for Feb29 1972 and Mar1 1972, and it will return values that mean that Jan1 1974 is two days after Dec31 1973.

    The gobble about UNIX epochs being a bad fit on a Windows server is just so much gobble, possibly because of bad anonymisation.

  • (cs) in reply to noname
    noname:
    But because 2000 is not a leap year

    Bzzzt. Thanks for playing.

  • noname (unregistered) in reply to hymie

    You got me. 2000 is dividable by 100 and 400.

  • Franky (unregistered) in reply to hymie
    hymie:
    noname:
    But because 2000 is not a leap year

    Bzzzt. Thanks for playing.

    For all those who still don't get leap years: every 4 years, except every 100 years, except every 400 years. So 1900 wasn't a leap year, but 2000 was as you can divide by 400 (seriously, we had to implement this in every language we learned at school as one of the first exercises)

  • L (unregistered) in reply to noname
    2000 is not a leap year
    2000 is a leap year. But this formula assumes that 1974, 1978 etc. are leap years.
    article:
    an application functioned as it was designed
    So 1974 is a leap year by design?
  • (cs)

    "If it ain't broke, don't fix it" So much for Code Excellence!

  • (cs) in reply to russ0519

    So it's OK to be wrong, as long as you're consistently wrong, except when you're not, except when you might be, except when you're really really wrong (then classify it as a feature request).

  • (cs) in reply to noname
    noname:
    It does account for leap years: (((year - 1970)/4) * DAY)

    But because 2000 is not a leap year the generated date is one day off. As long as both dates are between 1.1.2001 and 31.12.2099 no one will notice.

    ((2000 - 1970)/4) = 7.5, no?

  • Black Bart (unregistered)

    Yes, they didn't want to use the built in C# libraries, which handle dates past 2039 (Epoch seconds overflow a 32 bit integer).

  • Azarien (unregistered)

    The Y2.1K problem in the making.

  • (cs)

    Apart from all other things - did anyone notice that the DAY multiplication could be put outside the brackets?

    Not to mention that the /4 division could have been handled through bit shift;)

  • unmatched (unregistered) in reply to Scythe
    Scythe:
    Apart from all other things - did anyone notice that the DAY multiplication could be put outside the brackets?

    Not to mention that the /4 division could have been handled through bit shift;)

    Anyone notice the last bracket is not matched?

  • AverageNewbie (unregistered) in reply to cdosrun
    cdosrun:
    noname:
    It does account for leap years: (((year - 1970)/4) * DAY)

    But because 2000 is not a leap year the generated date is one day off. As long as both dates are between 1.1.2001 and 31.12.2099 no one will notice.

    ((2000 - 1970)/4) = 7.5, no?

    (2000 - 1970) / 4 = 7

    year is an integer.

  • Anna Moose (unregistered) in reply to Scythe

    "Not to mention that the /4 division could have been handled through bit shift;) "

    I see the smiley, but really, let's code what we intend to do, not how to do it.

  • (cs) in reply to ParkinT
    ParkinT:
    "If it ain't broke, don't fix it" So much for Code Excellence!

    I DESPISE that quote and the associated mentality with the fire of a thousand suns. Something can be "broke" and still appear to be working properly; doesn't mean it isn't broken and should be ignored.

    This mentality is the reason there is so much shitty software out there (and the reason this site exists) because people are so reluctant to mercilessly refactor code and follow good craftsmanship principles under this false pretense.

    The greatest lie in business is "The customer is always right". The second is "If it ain't broke, don't fix it".

  • Nickster (unregistered) in reply to emaN ruoY
    emaN ruoY:
    This comment was designed to be Frist.

    Your comment does not function as it was designed. I will submit a bug report.

  • Vilx- (unregistered)

    Wow, that's ingenious! Now just to convert those weird two-byte characters into proper 1-byte ASCII characters that don't waste memory like crazy!

  • Nagesh (unregistered) in reply to russ0519
    russ0519:
    So the WTF is that the developer thought that you can't use Unix Epoch on a windows server?

    Also Frist

    Junior developer often have elitist opinon to distract from lack of knowledge how system realy work.

    Also, if you omit "frist", I nominate ur post for featured coment.

  • Chris (unregistered) in reply to Nagesh

    WTF? There is no reason whatsoever to "optimize" for other platforms just because you might port the application sometime in the future. Using language specific functions when you can saves code, maintenance and usually gives you less potential bugs to worry about.

  • Brian E (unregistered)

    Sure, let's make something that will break on January 19, 2038. http://en.wikipedia.org/wiki/Year_2038_problem

  • (cs)

    TRWTF is 

    int strElapsedDays
    .

  • Bruce W (unregistered) in reply to ObiWayneKenobi

    [quote user="ObiWayneKenobi"][quote user="ParkinT"]"If it ain't broke, don't fix it" So much for Code Excellence![/quote]

    Agreed. I just finished a product that was so focused on the front end working that several key backend processes were forgotten all together. But, hey, the front end was pretty and worked "right".

  • (cs) in reply to minitech
    minitech:
    TRWTF is 
    int strElapsedDays
    .
    No, this is the *other* Hungarian notation, in this case showing that ElapsedDays is contaminated with STRangeness. Or that it is So Totally wRong.

    (Read about Hungarian notation some time. The original intent was that it would show stuff about the content of a variable that could not be captured in its type, such as that a "char *" points to a string rather than a single character, or that that string is zero-terminated, or more usefully that it is or is not XML-escaped or some such. So char *sMessageText is points to a string containing the raw message text, and char *xsMessageText points to the XML-safe version.)

  • (cs)

    The story omits the rather important detail of what information Jeff included in his bug report.

    If it was "it should use built-in date handling code rather than use a custom library based on Unix epoch," I can't fault the team for reclassifying it as a feature request.

    If he submitted two or three examples of dates that this code got wrong, then it's clearly wrong to treat it as anything but a bug.

  • Recursive Reclusive (unregistered)

    So what do we have:

    YEAR = 52*WEEKS (not used in this snippet, though) 1972, 1976, 1980 and so on are not handled as leap years 1974, 1978, 1982 and so on ARE handled as leap years Input year is never handled as a leap year

  • Nagesh (unregistered) in reply to Chris
    Chris:
    WTF? There is no reason whatsoever to "optimize" for other platforms just because you _might_ port the application sometime in the future. Using language specific functions when you can saves code, maintenance and usually gives you less potential bugs to worry about.
    You have very short-sight. Also, typical dual-shore site like mine have many aplication in sevaral langage, so it is being beter to have code which has ben rigorosly tested to avoid erors. This algorithm is being good since begining of epoch and recomended by Knuth in Art of Programing.

    Also, lern to use "quote" buton.

  • wtf (unregistered) in reply to Erlando

    ...or leap seconds

  • Anonymous (unregistered)

    If it ain't broke, you reviewed it wrong.

  • rioki (unregistered) in reply to cdosrun

    You do integer division much?

  • Nagesh (unregistered)

    Feke haker Nagesh is ruining my good name!

  • (cs) in reply to Nickster
    Nickster:
    emaN ruoY:
    This comment was designed to be Frist.

    Your comment does not function as it was designed. I will submit a bug report.

    Your bug report has been downgraded to a "feature enhancement request". Rationale: The comment does function as designed, which is to provide a commentary on the article. Desired ranking of Frist is noted, and will be slated for a future upgrade.

  • (cs) in reply to ParkinT
    ParkinT:
    "If it ain't broke, don't fix it" So much for Code Excellence!
    Fukushima's former dwellers applause with both three hands to this insightful saying.
  • (cs) in reply to AverageNewbie
    AverageNewbie:
    cdosrun:
    noname:
    It does account for leap years: (((year - 1970)/4) * DAY)

    But because 2000 is not a leap year the generated date is one day off. As long as both dates are between 1.1.2001 and 31.12.2099 no one will notice.

    ((2000 - 1970)/4) = 7.5, no?

    (2000 - 1970) / 4 = 7

    year is an integer.

    Don't most of the developed countries round up at .5?

  • (cs) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    ParkinT:
    "If it ain't broke, don't fix it" So much for Code Excellence!

    I DESPISE that quote and the associated mentality with the fire of a thousand suns. Something can be "broke" and still appear to be working properly; doesn't mean it isn't broken and should be ignored.

    This mentality is the reason there is so much shitty software out there (and the reason this site exists) because people are so reluctant to mercilessly refactor code and follow good craftsmanship principles under this false pretense.

    The greatest lie in business is "The customer is always right". The second is "If it ain't broke, don't fix it".

    Thank you for your input. Your cheque is in the post. (In case you don't understand English, that means: your check is in the mail.)

  • (cs)
    When Jeff got his hands on the code, one line in particular caught his eye: 
    int strElapsedDays = ( 
     convertDate(intDay1, intMonth1, intYr1) - 
     convertDate(intDay2, intMonth2, intYr2)) / DAY;

    Knowing that C# had built-in functions to easily determine the span of days between two dates, Jeff thought the approach was a little strange.

    That's all that's strange? Passing dates around as three ints rather than using a DateTime isn't strange per se?

  • W. (unregistered) in reply to PiisAWheeL
    PiisAWheeL:
    AverageNewbie:
    cdosrun:
    noname:
    It does account for leap years: (((year - 1970)/4) * DAY)

    But because 2000 is not a leap year the generated date is one day off. As long as both dates are between 1.1.2001 and 31.12.2099 no one will notice.

    ((2000 - 1970)/4) = 7.5, no?

    (2000 - 1970) / 4 = 7

    year is an integer.

    Don't most of the developed countries round up at .5?

    Implicit conversion from floating point to integer always just truncates, cuts off anything after the decimal point. There's no automatic rounding off, and that's why there are usually some standard library functions like round() and ceil() to make explicit which rule to follow. (int) 7.99 = 7 (int) -3.99 = -3

  • (cs) in reply to PiisAWheeL
    PiisAWheeL:
    Don't most of the developed countries round up at .5?
    Only sometimes. Computers doing integer division usually round toward -Inf. So-called "conventional" rounding rounds away from zero at 0.5. Banker's rounding rounds even.5 toward zero and odd.5 away.
  • Nagesh (unregistered)

    Here in Hyderabad, explaination of integer rounding in CS is first computer coarse that freshman take.

  • Anon (unregistered) in reply to PiisAWheeL
    PiisAWheeL:
    AverageNewbie:
    cdosrun:
    noname:
    It does account for leap years: (((year - 1970)/4) * DAY)

    But because 2000 is not a leap year the generated date is one day off. As long as both dates are between 1.1.2001 and 31.12.2099 no one will notice.

    ((2000 - 1970)/4) = 7.5, no?

    (2000 - 1970) / 4 = 7

    year is an integer.

    Don't most of the developed countries round up at .5?

    Please tell me you're trolling and not really that stupid! This is truncation, not rounding.

  • derp (unregistered) 
    private static int convertDate(int day, int month, int year)
{
 
  int[] months = new int[] 
     { 0,31,59,90,120,151, 
       181,212,243,273,304,334 };

  return ( ((year - 1970) * DAY * 365) + 
           (((year - 1970)/4) * DAY) + 
           (months[month - 1] * DAY) + ((day-1) * DAY) );
}

    TRWTF is the ridiculous formatting. Why Must every thing get its own line

  • Anon (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    PiisAWheeL:
    Don't most of the developed countries round up at .5?
    Only sometimes. Computers doing integer division usually round toward -Inf.

    No they don't. Example:

    -9 / 2 = -4.5 truncates to -4 (i.e. towards +Inf, not -Inf)

    So-called "conventional" rounding rounds away from zero at 0.5. Banker's rounding rounds even.5 toward zero and odd.5 away.

    And Banker's rounding is TRWTF!

  • Anon (unregistered) in reply to derp
    derp:
    private static int convertDate(int day, int month, int year)
{

    int[] months = new int[]
{ 0,31,59,90,120,151,
181,212,243,273,304,334 };
    

    return ( ((year - 1970) * DAY * 365) +
(((year - 1970)/4) * DAY) +
(months[month - 1] * DAY) + ((day-1) * DAY) );
}

    TRWTF is the ridiculous formatting. Why Must every thing get its own line

    We don't all have fancy wide- screen monitors you insensitive clod!

  • (cs) in reply to Anon
    Anon:
    PiisAWheeL:
    AverageNewbie:
    cdosrun:
    noname:
    It does account for leap years: (((year - 1970)/4) * DAY)

    But because 2000 is not a leap year the generated date is one day off. As long as both dates are between 1.1.2001 and 31.12.2099 no one will notice.

    ((2000 - 1970)/4) = 7.5, no?

    (2000 - 1970) / 4 = 7

    year is an integer.

    Don't most of the developed countries round up at .5?

    Please tell me you're trolling and not really that stupid! This is truncation, not rounding.

    Keep your panties on man. I was thinking in math, not computer. Sometimes, when you don't experience a certain problem in a long time and you forget some of the details.

  • Other Nagesh (unregistered)

    TRWTF is "to the bug-fix queue for the offshore team"

Leave a comment on “Epoch Billing System”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article