Comment On Epoch Billing System

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

Also Frist

scond


not spam

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?

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

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.

This comment was designed to be Frist.

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.

noname:

But because 2000 is not a leap year

Bzzzt. Thanks for playing.

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

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)

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?

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

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

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?

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

The Y2.1K problem in the making.

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

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?

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.

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

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

emaN ruoY:

This comment was designed to be Frist.

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

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!

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.

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.

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

TRWTF is

int strElapsedDays

.

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

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

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.

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

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.

...or leap seconds

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

You do integer division much?

Feke haker Nagesh is ruining my good name!

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.

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.

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?

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

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?

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

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.

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

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.

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

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!

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!

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.

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