| « Prev | Page 1 | Page 2 | Page 3 | Page 4 | Next » |
Entirely correct, but not the point, as neither 7.5 nor 7 handles any leap years correctly. |
Re: Epoch Billing System
2012-05-10 16:56
•
by
Ben Jammin
(unregistered)
|
It's a Nagesh grammar nazi. I thought I'd never see the day. |
|
TRWTF is that some annoying and immature little bitch is trolling this forum by pretending to be Nagesh. Nagesh is a registered user of this site. If you see that the author of a comment is Nagesh(unregistered), you should treat the comment as spam.
Genuine Nagesh comments are (sometimes) funny when used sparingly. When some immature little script kiddie comes onto this forum and repeats the same joke that he stole from someone else over and over again, it makes TDWTF less enjoyable for everyone. |
Re: Epoch Billing System
2012-05-10 17:45
•
by
Nagesh (registered)
(unregistered)
|
What is mean "script kiddie"? Me English to Indian dictionary say "parchment goat", make nonsens. |
Re: Epoch Billing System
2012-05-10 17:46
•
by
secundum
(unregistered)
|
I have unregistered Nagesh. Pray that I don't unregister him further! |
Re: Epoch Billing System
2012-05-10 17:46
•
by
secundum
(unregistered)
|
I have unregistered Nagesh. Pray that I don't unregister him further! |
|
"Jeff had to admit, the solution was a little bit genius. "
I wouldn't say so. Genius is not writing your own calendar functions. You asking for trouble there because there are a thousand caveats. Every system has its own properties such as favouring accuracy or practicality. If you make yet another one, you have even more to reconcile with when integrating with dates from another source. Fortunately for him, unixtime is designed for practicality, not accuracy. A second is not a fixed duration in unixtime. For billing, where date is more important than time (at least down to the second). 10 minutes is way too long to workout what that is doing. He might survive even with that unchecked loss of precision via division and failure to work out the days difference and they times that by DAY last of all. But can he survive missing -2 for his leap year calculation? |
Re: Epoch Billing System
2012-05-10 18:11
•
by
WTF
(unregistered)
|
Excellent. Now you can get in on that Google IPO in a few years. And you can short-sell your way to wealth when the dot-com crash comes around again. And you can profit again from the stock market crash of 2008. By the time 2012 comes around again, you should be a very wealthy man. |
|
Hey, if aint' broke, don't fix it.
|
Re: Epoch Billing System
2012-05-10 18:37
•
by
gnasher729
(unregistered)
|
|
It's not so much that it makes 1974 a leap year. Leap years are usually defined as years that have an extra day on 29th of February. With this code, the extra days are 32nd of December 1973, 1977, 1981 and so on.
|
|
So it was posted in Visual Studio magazine... no wonder.
staring, uhm... 10 minutes? it's more than obvious. whats so genius about that? i guess some geniuses just haven't heard about mktime. |
|
return ((year-1970)*365+((1970+3+-year)>>2)+months[month-1]+day+(year%4==0&&month>2))*DAY;
That might fix it. At least it's more readable. No more having to shift your eyes around the place. But I don't know C# or mathematics. I'm merely a binman with a GCSE level C in maths. |
Re: Epoch Billing System
2012-05-10 18:51
•
by
EvilTeach
(unregistered)
|
|
2000 was a leap year
|
Re: Epoch Billing System
2012-05-10 19:07
•
by
blowhole
(unregistered)
|
Oops, there is a mistake. Make that: return ((year-1970)*365+(year-1973>>2)+months[month-1]+day+(year%4==0&&month>2))*DAY; Now even easier to read. |
|
Here you go. Sorry, it's Python.
seconds_jan_1_0000_to_jan_1_1970 = 62167132800 leap_year = (year % 4 == 0) and ((year % 100 != 0) or (year % 400 == 0)) seconds_since_jan_1_0000 = ((day - 1) * DAY) + (months [month - 1] * DAY) + (DAY if leap_year and month > 2 else 0) + (int (year * 365.2425) * DAY) return seconds_since_jan_1_0000 - seconds_jan_1_0000_to_jan_1_1970 |
Re: Epoch Billing System
2012-05-10 20:36
•
by
Robert B.
(unregistered)
|
|
Um, print out the code? For what purpose? Making paper airplanes?
My 24" monitor can have as many toolbars next to it as I want. So can my 22" monitor, even though it gives up 2". Get a monitor from this century and find an employer with a hardware budget of more than $5 per developer. |
Re: Epoch Billing System
2012-05-10 20:45
•
by
Robert B.
(unregistered)
|
"Regular" rounding (round half-up) is asymmetric. Banker's rounding is symmetric. When you're dealing with billions of transactions a day worth trillions of dollars, that kind of matters. "Regular" rounding is naive and should probably never be used if calculation of monetary amounts is involved. |
Re: Epoch Billing System
2012-05-10 21:16
•
by
blowhole
(unregistered)
|
FUUUUU... 1970-year+3. Are you sure it works? Here is a tester you can use in PHP:
A generator for the dates you will need for your test case:
|
Re: Epoch Billing System
2012-05-10 21:50
•
by
dxf
(unregistered)
|
I could have sworn 2000 WAS a leap year, or am I 1 day off? (hint: Leap years occur every 4 years, unless the year happens to end with 00 in which case they only occur if the year is divisible by 400) |
Re: Epoch Billing System
2012-05-10 21:52
•
by
dxf
(unregistered)
|
Never mind, I must be 1 day off, because approximatel 72 people have already said this |
Re: Epoch Billing System
2012-05-10 23:49
•
by
Meep
(unregistered)
|
FTFY. Fucking stupid electrical engineers. |
Re: Epoch Billing System
2012-05-11 00:27
•
by
KB
(unregistered)
|
Easy to say but... If we would always strive to fix what appears to work "because it wasn't done properly" nothing would get done exact refactoring. Firstly because there is so much shit out there, secondly because no 2 people would agree on what's good practice - and why should your idea of good practice be any more valid than mine? So you walk in and say "My God, people! This has to be the stupidest way to do things" and refactor everything. Some years later, you leave, and the next expert says "My God, people!! This is a stupid way to be implementing this stuff. Our first task has to be to do this properly". While you're right, things should get done properly it should be noted that "properly" is subjective and if coders were given the license to dictate what is and what ain't proper then those same nimrods that are writing the shyte right now would be clobbering your good code anyway, so we all still lose.... Unfortunately, the real world doesn't (and I thin can not) work as well as any theoretical world we might try to live in, and once we start arguing about doing things "right" we first need a way of deeming that something is or isn't right (which usually means someone above the techo who doesn't understand enough to even have an opinion about what is right beyond "But it works now, right?"). That's my 2c. I'm Kent Brockman |
Re: Epoch Billing System
2012-05-11 00:31
•
by
More Pizza
(unregistered)
|
Perhaps....now try your programming language of choice and tell us whether that does....what the "developed world" does (or doesn't) do is a bit inconsequential |
Re: Epoch Billing System
2012-05-11 00:36
•
by
Sarendar
(unregistered)
|
It a little creature with 6 leg that bite yous on leg when sitting in parks for nicpicking... |
Re: Epoch Billing System
2012-05-11 00:38
•
by
catastrophic
(unregistered)
|
And if you ever revisit code you wrote 2+ years ago you will likely find plenty of ugly stuff that you would do differently if you were the original coder. Many a time I have had to admit the "bad programming" causing issue today is a result of the knowledge I didn't have yesterday. We all start somewhere, and very few are instantly great programmers - even the best of us (read: me) have written some crap somewhere along the way.... |
Re: Epoch Billing System
2012-05-11 00:39
•
by
a;wo
(unregistered)
|
I remember thinking 2000 was a long ways away.... |
Re: Epoch Billing System
2012-05-11 00:44
•
by
AA
(unregistered)
|
And you'll probably find (if your program lasts that long) that whoever inherits your fixes will find some gems in there that make them go 'huh?' too. One of the issues (made abundantly clear by reading this site) is that in IT there are usually infinite (or close enough to infinite) ways to fix a certain issue. Not all are right, and not all are wrong, but opinions certainly differ on best approaches. Compare this to a mechanic who simply has to decide on the brand of a component and then make it fit the missing part he's replacing....Our role as IT experts is a lot vaguer (which is why most of us have to attend tertiary institutions at some stage to get something that evidences the fact we might actually be able to solve problems) |
Re: Epoch Billing System
2012-05-11 00:48
•
by
Nagesh number 45
(unregistered)
|
Actually, I still believe Nagesh is a real Indian pretending to be an American pretending to be an Indian... |
Re: Epoch Billing System
2012-05-11 00:57
•
by
Drury
(unregistered)
|
Actually, there were good C programmers too who understood reuse. Just like there are good VB....never mind.... I actually wish more people understood C - not necessarily wrote in C, but understood it.... I've people (mainly in C#, but other languages too) implement bit strings as strings (if(X.at(5) == '1')), repeatedly create new data structures (because they don't understand the underlying work), reuse functions to get variables instead of storing what the value is, etc, etc... Sure, to make a sudoku solver or a maze application on your desktop the overhead is unnoticeable, but when you write an app that will have many users and performance is critical...well...good to understand what is happneing under the hood. By all means use C#, Java etc (including all the nice data structures that have been made by someone who understands the world far better than you ever will) but write even a simple Linked List in C and you might begin to understand the work that is happening each time you say "new" (and the implicit "delete" (free) that comes with it). C is cumbersome, old fashioned etc - by all means use an OO program that is easy to use but UNDERSTAND WHAT IS GOING ON and you will be a better programmer. Boy did I sail off course... |
Re: Epoch Billing System
2012-05-11 01:01
•
by
FFS
(unregistered)
|
a) speaks for yourselve b) that would cut input here to about 20 comments pre post (just repeating: letation and apellation is awesome captha's) |
Re: Epoch Billing System
2012-05-11 03:03
•
by
L.
(unregistered)
|
I'm glad I didn't go to your school, it sounds awfully boring. |
Re: Epoch Billing System
2012-05-11 03:05
•
by
L.
(unregistered)
|
I personally have no problem not giving a fuck and letting it flow into a 64bit int. |
... and they're perfectly right. Why report the usage of unix epoch as a bug, instead of reporting a REAL bug in the way it was done? |
Why would I pretend to be American? I am not getting your logic, Mr 45. |
Re: Epoch Billing System
2012-05-11 05:47
•
by
Bartholomew Taps
(unregistered)
|
|
If it took "Jeff" 10 minutes to see what that function is trying to do, maybe he should consider a career in a call centre or perhaps in-store customer service.
|
Re: Epoch Billing System
2012-05-11 05:58
•
by
Recursive Reclusive
(unregistered)
|
Also the reform was in 1582. Did no one notice Nick V was off by 270 years? Seriously? |
Re: Epoch Billing System
2012-05-11 07:08
•
by
Sean
(unregistered)
|
|
2000 was a leap year. i was there.
century years only avoid being a leap year if they're not also millenium years. |
Re: Epoch Billing System
2012-05-11 07:45
•
by
Stev
(unregistered)
|
Yes, it IS better to have code that is rigorously tested - you know, like language provided functions that millions of developers will use as opposed to some code you wrote yourself to use in all your applications over what, a 10 year period? Believe it or not, the former will have been tested more. The problem really comes to light with code like this that probably works in this context 99.9% of the time, until you happen to hit a specific date. For example, next time there's a leap year - or possibly the next time there isn't. Sony had this problem with the PS3 a few years ago when it was expecting a leap year in 2010: http://blog.us.playstation.com/2010/03/01/playstation-network-service-restored/ This only came about after the PS3 had been on sale for a few years and used by millions of people daily. The above code is a proper WTF because there's plenty of cases where it's flat out wrong, so it's not really defensible. This happens nearly every time you try to reinvent the wheel because too many programmers think they know better than every other programmer out there. So what if you're porting code to a language that doesn't have a similar function, write the function for that language alone and leave it at that. Unless, of course, your goal is to ensure that all bugs are reproducible on all systems. |
Re: Epoch Billing System
2012-05-11 08:19
•
by
khermitt
(unregistered)
|
Ouch! After the correct algorithm has been shown here a dozen times already, how can someone still get it wrong? |
|
Many Pakistani here write bad date code to show superiority of luner calender. Prob why iPhone have problam every leep year.
|
Re: Epoch Billing System
2012-05-11 08:54
•
by
Anon
(unregistered)
|
Rubbish. Rounding .5 up is symmetric where as banker's "rounding" is totally arbitrary and stupid. You might as well flip a coin and decide whether you are going to round up or down. If we have a number 5.x: if x = 0 -> round down to 5 1 -> round down to 5 2 -> round down to 5 3 -> round down to 5 4 -> round down to 5 5 -> round up to 6 6 -> round up to 6 7 -> round up to 6 8 -> round up to 6 9 -> round up to 6 So for 5/10 values of x, the answer is 5. For 5/10 values of x, the answer is 6. That is symmetric. And considering that rounding is about precision, you have to consider that there are unknown decimals beyond what you are looking at. So if we round to 0 d.p.: 2.5000000000000000000000000001 Using regular sensible rounding, you get 3. Using bankers rounding, you get 2. Clearly regular rounding is better because the number is closer to 3 than 2. |
Re: Epoch Billing System
2012-05-11 09:01
•
by
eagle275
(unregistered)
|
No - the WTF is that this code is PLAIN WRONG - at least it does not correctly incorporate the rules for leap years as defined by Pope Gregor VII (at least after my memory) first - (year-1970) / 4 would incorrectly make 1974 , 1978 and so on a leap year, instead of 1972, 1976 and so on second - it does not recognize that years dividible by 100 but not by 400 are NOT leap years (1900 was not a leap year) - sure this would occur 2100 for the first time, but a bug remains a bug third - on computers which follow DST (about EVERY Windows- and Windows-Server-PC) this will produce wrong results for the days within Daylight-period (march to october) - as the starting day of DST only has 23 hours (you move the clock from 2 to 3 , stealing 1 hour) and this hour is corrected at the end ... so you are advised to use the build in date-time-functions which USUALLY support differencies created by DST (even if only by giving them another parameter) so basically if your system is a "billing" system, I assume its tasks contain automatic escations, when a billing period is missed (even if only by 1 day) - and here you have a system that will erroneously assume every day between 23:00 and midnight to be on the next day - so you might miss you payment period due to bank working methods. I would assume a pile of annoyed customers - and this is clearly not a feature request |
Re: Epoch Billing System
2012-05-11 09:05
•
by
Unknown User
(unregistered)
|
|
Not necessarily wrong, perhaps Sean’s definition of millennium is a time period of 400 years…
I think perhaps one reason why programmers can not even agree which of several ‘correct’ implementations is the ‘better’ implementation is because language sucks. We cannot always even agree on what a given word means, or how to spell it. If Sean wants to call a quad-a-centurion a millennium it is perfectly acceptable. If you want to call a fish a turtle it is also perfectly acceptable. We just need to know the in-depth definition of every word’s usage, as used by another to fully judge if they are right or wrong. |
|
It does account for leap years for the next century at least, but what about leap seconds? and what about timezones? and what about daylight savings? It is obvious the original programmer doesn't have a single clue about how to handle dates in software.
|
Re: Epoch Billing System
2012-05-11 09:27
•
by
L.
(unregistered)
|
I totally agree, fuck bankers. |
Re: Epoch Billing System
2012-05-11 09:38
•
by
PedanticCurmudgeon
|
FTFY |
Re: Epoch Billing System
2012-05-11 09:44
•
by
the beholder
(unregistered)
|
That logic, my dear sir, may appear ok but is definitely flawed. I'll show you: If we have a number 5.x: if x = 0 -> doesn't round at all, because it's already round 1 -> round down to 5 2 -> round down to 5 3 -> round down to 5 4 -> round down to 5 5 -> the point of controversy 6 -> round up to 6 7 -> round up to 6 8 -> round up to 6 9 -> round up to 6 When you round 9 up you're deviating by the same amount as rounding 1 down, so they cancel each other. But 5 doesn't cancel with 0: one is the worst possible deviation and the other is no deviation at all. That's why there are algorithms that do not round 5 the same way every time. |
Re: Epoch Billing System
2012-05-11 09:47
•
by
Maurizio
(unregistered)
|
|
While in spirit i fully agree, i wonder what do you propose when the code to refactor/rewrite is about 20 million lines or more :-<
|
Re: Epoch Billing System
2012-05-11 10:05
•
by
L.
(unregistered)
|
Well if you rewrite it correctly, it'll go down at least two orders of magnitude so don't think it's impossible ;) Do it bit by bit, and get paid a fckton doing it is what I propose. |
Re: Epoch Billing System
2012-05-11 10:21
•
by
Nickster
(unregistered)
|
Straight answer: it's a regionalism for "isn't," "aren't," or "am not." |
| « Prev | Page 1 | Page 2 | Page 3 | Page 4 | Next » |
AverageNewbie: