Comment On Epoch Billing System

Everybody in the IT department was quite happy -- even a little surprised -- with how well the outsourced project to replace the legacy billing system was progressing. [expand full text]
« PrevPage 1 | Page 2 | Page 3 | Page 4Next »

Re: Epoch Billing System

2012-05-10 09:02 • by russ0519
So the WTF is that the developer though that you can't use Unix Epoch on a windows server?

Also Frist

Re: Epoch Billing System

2012-05-10 09:06 • by me (unregistered)
scond


not spam

Re: Epoch Billing System

2012-05-10 09:08 • by 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?

Re: Epoch Billing System

2012-05-10 09:10 • by Erlando (unregistered)
It doesn't account for leap years correctly...

Re: Epoch Billing System

2012-05-10 09:15 • by 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.

Re: Epoch Billing System

2012-05-10 09:16 • by emaN ruoY (unregistered)
This comment was designed to be Frist.

Re: Epoch Billing System

2012-05-10 09:16 • by Steve The Cynic
380739 in reply to 380736
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.

Re: Epoch Billing System

2012-05-10 09:18 • by hymie
380740 in reply to 380737
noname:
But because 2000 is not a leap year


Bzzzt. Thanks for playing.

Re: Epoch Billing System

2012-05-10 09:20 • by noname (unregistered)
380741 in reply to 380740
You got me.
2000 is dividable by 100 and 400.

Re: Epoch Billing System

2012-05-10 09:22 • by Franky (unregistered)
380742 in reply to 380740
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)

Re: Epoch Billing System

2012-05-10 09:22 • by L (unregistered)
380743 in reply to 380737
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?

Re: Epoch Billing System

2012-05-10 09:25 • by ParkinT
"If it ain't broke, don't fix it"
So much for Code Excellence!

Re: Epoch Billing System

2012-05-10 09:31 • by snoofle
380745 in reply to 380733
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).

Re: Epoch Billing System

2012-05-10 09:35 • by cdosrun
380746 in reply to 380737
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?

Re: Epoch Billing System

2012-05-10 09:38 • by 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).

Re: Epoch Billing System

2012-05-10 09:40 • by Azarien (unregistered)
The Y2.1K problem in the making.

Re: Epoch Billing System

2012-05-10 09:45 • by 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;)

Re: Epoch Billing System

2012-05-10 09:48 • by unmatched (unregistered)
380750 in reply to 380749
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?

Re: Epoch Billing System

2012-05-10 09:49 • by AverageNewbie (unregistered)
380751 in reply to 380746
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.

Re: Epoch Billing System

2012-05-10 09:49 • by Anna Moose (unregistered)
380752 in reply to 380749
"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.

Re: Epoch Billing System

2012-05-10 09:50 • by ObiWayneKenobi
380753 in reply to 380744
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".

Re: Epoch Billing System

2012-05-10 09:52 • by Nickster (unregistered)
380754 in reply to 380738
emaN ruoY:
This comment was designed to be Frist.


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

Re: Epoch Billing System

2012-05-10 09:53 • by 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!

Re: Epoch Billing System

2012-05-10 09:56 • by Nagesh (unregistered)
380756 in reply to 380733
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.

Re: Epoch Billing System

2012-05-10 09:57 • by Chris (unregistered)
380757 in reply to 380735
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.

Re: Epoch Billing System

2012-05-10 10:03 • by Brian E (unregistered)
Sure, let's make something that will break on January 19, 2038.
http://en.wikipedia.org/wiki/Year_2038_problem

Re: Epoch Billing System

2012-05-10 10:04 • by minitech
TRWTF is
int strElapsedDays
.

Re: Epoch Billing System

2012-05-10 10:07 • by Bruce W (unregistered)
380760 in reply to 380753
[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".

Re: Epoch Billing System

2012-05-10 10:12 • by Steve The Cynic
380761 in reply to 380759
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.)

Re: Epoch Billing System

2012-05-10 10:15 • by Rootbeer

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.

Re: Epoch Billing System

2012-05-10 10:15 • by 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

Re: Epoch Billing System

2012-05-10 10:17 • by Nagesh (unregistered)
380764 in reply to 380757
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.

Re: Epoch Billing System

2012-05-10 10:18 • by wtf (unregistered)
380765 in reply to 380736
...or leap seconds

Re: Epoch Billing System

2012-05-10 10:20 • by Anonymous (unregistered)
If it ain't broke, you reviewed it wrong.

Re: Epoch Billing System

2012-05-10 10:21 • by rioki (unregistered)
380767 in reply to 380746
You do integer division much?

Re: Epoch Billing System

2012-05-10 10:31 • by Nagesh (unregistered)
Feke haker Nagesh is ruining my good name!

Re: Epoch Billing System

2012-05-10 10:36 • by RichP
380769 in reply to 380754
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.

Re: Epoch Billing System

2012-05-10 10:55 • by toshir0
380771 in reply to 380744
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.

Re: Epoch Billing System

2012-05-10 10:57 • by PiisAWheeL
380772 in reply to 380751
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?

Re: Epoch Billing System

2012-05-10 11:00 • by Matt Westwood
380773 in reply to 380753
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.)

Re: Epoch Billing System

2012-05-10 11:12 • by pjt33
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?

Re: Epoch Billing System

2012-05-10 11:30 • by W. (unregistered)
380776 in reply to 380772
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

Re: Epoch Billing System

2012-05-10 11:32 • by Steve The Cynic
380777 in reply to 380772
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.

Re: Epoch Billing System

2012-05-10 11:39 • by Nagesh (unregistered)
Here in Hyderabad, explaination of integer rounding in CS is first computer coarse that freshman take.

Re: Epoch Billing System

2012-05-10 11:42 • by Anon (unregistered)
380779 in reply to 380772
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.

Re: Epoch Billing System

2012-05-10 11:43 • by 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

Re: Epoch Billing System

2012-05-10 11:45 • by Anon (unregistered)
380781 in reply to 380777
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!

Re: Epoch Billing System

2012-05-10 11:48 • by Anon (unregistered)
380782 in reply to 380780
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!

Re: Epoch Billing System

2012-05-10 11:58 • by PiisAWheeL
380784 in reply to 380779
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.

Re: Epoch Billing System

2012-05-10 12:00 • by Other Nagesh (unregistered)
TRWTF is "to the bug-fix queue for the offshore team"
« PrevPage 1 | Page 2 | Page 3 | Page 4Next »

Add Comment