Just find a personal itch to scratch and scratch it.
Doesn't have to be something you'll release, but being able to show it in action is an interview booster (thus, if it is mobile, all the better). The fun part is that once it is scratched and you decide to move it somewhere else into the cloud for more permanent hosting, there's another itch to scratch.
Case in point, I put together a shopping list manager using node/express/mongo and jquery/jquery mobile/stativus. Then found that if I were to deploy it at my webhost, I don't have mongo so I then needed to learn an ORM system for node to mysql (using bookshelf js right now). Similarly if you build something in mongo, you can look to learning AWS or Google Cloud Development and get the app out there and there's another skill on the resume checklist.
In fact, doing the database port actually helped me develop and refine unit testing so my data-access layers had the same front API - knowing you're replacing a single piece actually encourages writing the pieces to be more modular and independent.
All javascript, plenty of html5 modern architecture skills learned or refined, and this from someone who spent most of the mid-late 2000s as a J2EE w/ Oracle guru.
In addition to "all of the above", the other contribution is that of the philosophical equivalent of Heisenberg: the predictions of outbreaks may have increased vaccination usage in the areas involved, which of course will have an effect of downplaying the outbreaks in those areas.
Not saying I have any evidence for that, (and I will wager it unlikely, considering the #s who vaccinate is still far lower than it should be), but a correlation study may be interesting to see.
If the point of knowledge of a possible outcome is to act to deter it, then shouldn't the actions that attempt to deter it be taken into account?
heh. I do wonder if their use of these is considered 'fair use' or if, like in the case of the Obfuscated C entry, it really is a copyright violation and the coders should get compensated?:)
I'm inclined to agree - "malaise" is an opinion, seen better from the outside than within. Ask any social commentator to look at today's workers or kids, with how much they 'veg' in front of a TV or on a computer, and you definitely know that the work itself, with the rare exception, is not in any way fulfilling.
He was right in that automation doesn't necessarily lead to total unemployment: it changes the jobs, and within a company it reduces them, but on the whole we've more jobs now than we did then (as we have more than twice as many people, but close to the same employment rate as we did then), so the system adapts to unemployment, eventually.
I don't think he was using the term 'spiritually' to in any way imply any aspect of religion, so those that interpret it that way are misreading him.
perhaps true...but then I wasn't coding on a laptop in the 4x3 era.:)
and even so, I still live in alt-tab hell because a laptop screen, no matter that it is 1440x900, can't get me my code, my web browser large enough to see the space I'm fixing, and the firebug console to figure out what the bleep is wrong with it, all at the same time.
all that said, the idea of very small pixels on a laptop-sized screen doesn't necessarily make things more readable. For a tablet where you can use vertical orientation to read, it might be better, but on a laptop that is fixed horizontal orientation, I can't see it being that much use for text, and while it may render a blue-ray more accurately, your eyes won't know the difference at that size.
(oh, and in addition to fixing it, I have a thunderbolt monitor for my mac laptop at work, and an imac with a larger screen ratio, too...and i've yet to meet a mac developer who wants to go back to a mere 1080 after finally getting a screen with serious real estate like that.)
I fixed it. I said I fixed it for myself: I have one monitor in vertical orientation. I also shrunk my font size down to 7 point. Seems to work, I can generally get most of a file on the screen at once.
why did it not catch on? Because the display was horrendously expensive since it was so mostly unique, compared to CRT components for 4x3 screens that were extremely cheap and off-the-shelf. It had nothing to do with coder preference at the time and EVERYTHING to do with how much a corporation was willing to spend on its coders. As such, few outside of Xerox even got to try it. Nobody knew what they were missing, because everybody knew it, "wasn't that difficult to work around".
Still, maybe someday it might be nice to have better options and better designs out there instead of stuff that "isn't that difficult to work around." Coding and building the right thing (or a more flexible thing but with better default settings) should be inherent in interface design, but it still isn't, because coders like you seem to be just fine with stuff that "isn't that difficult to work around."
Because of entertainment sources, laptops and desktop monitors are all wide-screen 16x9......but that resolution ONLY works for entertainment video. Reading requires vertical height and narrow width (books are the shape they are for a reason), so the more horizontal space that is given at the loss of vertical, the less comfortable reading and writing (and *coding*) are because one can't fit enough vertical lines on the page to be able to speed-scan for context, and at other times someone doesn't bother to limit their readable space width (or it is a plain text file) and so the horizontal line goes well beyond the comfortable 10-12 word limit.
In short, it just doesn't work when the medium is text. (Say what you will about the coming illiterate age at this point...)
1080 is actually very uncomfortable for those of us who were coding in 1440x1280 4x3's prior to the HDMI standard locking us all down to 1080. I personally keep an external monitor rotated 90degrees in order to have a decent working space, separate from my "entertainment" and browsing space.
Who else had a long vertical orientation to the monitor, knowing it was a better way to work? Xerox PARC.
(and gee, many of our problems in Education go away when one addresses the poverty issue that makes education impossible rather than constantly trying to change the education system that has otherwise worked for generations)
So long as we just focus on *treatment* of the sick, costs will continue to spiral.
A general influx of cash doesn't just focus on treatment of those sick - it starts to alleviate the issues that allow disease to spread in the first place (lack of hygene, lack of vaccination, lack of clean water, lack of balanced food (and complete meals), and lack of general preventive care, and lack of birth control - ALL things people in poverty already lack).
Health care costs get under control when the focus is on prevention rather than treatment: you spend FAR less money when fewer people get sick. When you use the capital to address the causes of disease rather than just treating it, you spend much less on treating the ones that got away.
Relatedly, this is why insurance companies love birth control - a pill a day and a box full of condoms is far cheaper to them than the thousands of dollars for examinations, the birth, emergency natal care, and having to cover the kid for the next 26 years.
Recent obnoxious examples include Facebook (the one bundled with my phone was 9meg. The current is 34m + almost as much data memory used up), and Amazon's app store (a 5 meg app that brings in more than 17 and sometimes as high as 49 meg tagged *data*, not cache).
I dropped amazon from my phone (an older HTC Evo, so it only has 160 meg or so for app+data) because of this, and just gave up on those apps I'd purchased through it (some of which were on google play). Even so, any time I need to update FB, I generally have to wipe the data out to make room for the download.
In CS, the killer is usually electro-magnatism or calculus-level probability. In Physics, it is usually diff-eq's. In math, it is usually partial diff-eq's.
Yes, the exceptions to the "rules" in org-chem is maddening...but if it wasn't, prescriptions and pharmaceuticals would be easy. Instead, they are rife with mistakes, side effects, false-positives, and a lot worse, and if you don't have the background to understand at least to a degree why, then I'll be damned before I let you write me a prescription for anything.
But seriously, this is college leading to one of the toughest post-grad programs our society has to offer. It is supposed to be hard. Deal with it or get out.
Which was my point, I thought I made clear, from the very beginning. Keeping up with software updates (that theoretically aren't supposed to change anything unless they make it better, even if it means an API difference to code to) is one thing. Generally, one can hold back a patch and coordinate it with some other release cycle.
Having to adapt to an arbitrary, non-technical reason mandated by a clueless government is something else, a very EXPENSIVE, something else, as it is as i noted, something that adds no value to the product but costs as much as a new large feature would. And in this case, the deadline wasn't set by us either, but by the same government - we couldn't hold the patches back. Quite the opposite, we needed to get them in and tested ASAP as customers using our app to project into the future needed to have that date information accurate.
My response (see the title this thread has had all along) was in response to the continual suggestions that happen twice a year, every year, right on schedule, for getting rid of DST, but clueless dolts who think it is "easy" to do and wouldn't have any impact except some alleged positive one based on some analyst's arbitrary definition of "productivity". While getting rid of DST might eventually have a long term benefit, it will still have an expensive short-term cost that needs to be carefully considered based on the experiences of 2005-2007.
Just having some database isn't enough in and of itself. One needs to be able to process it and interpret it correctly so that it "makes sense" to the business model one is using.
In addition, code that looks backwards in time (reporting engines, for example, or event history viewers) need to be able to use the old rules as they look back, while looking at the current (and potentially new) rules looking forward, and have to know at what year/date some country made the decision to cut DST. This is a reason the TZ folder/file on linux boxes (for example) is as large as it is.
No, we're not mission-critical like medical stuff, but that doesn't stop the customer base from griping when the DST-handling code was broken before I was assigned to fix it.
And this DST issue is somewhat different from what I was originally ranting about, which was the amount of work I was going through building test plans and cases for actually being able to see if the software I was working on at the time handles the DST change correctly, coordinating and tracking all of the OS and software patches (there were 10 updates to Java's JDK/JVM alone in a matter of 5 weeks, ALL related to this issue) and ensuring our stuff would work.
It isn't the best at all. I inherited this API. Trying to see if we can take the pressure off by having the API send a date-time string back instead of making the UI responsible for the epoc conversion, so the server (with much better resources) becomes responsible for it. As it is a published API for our customers to also use, it is a pretty big change to do that.
That said, I've been rather proud of what I've managed to achieve so far with the limited resources I've got.
Currently I am having to track and get our system up to date for several other countries timezones that have changed their DST rules in the last 5 years, like Iraq and Egypt (both dropped DST entirely), plus trying to figure out, without actually coding a lunar calendar into my system, when Brazil postpones their DST end date by a week to avoid closing Carnivale early (yeah, lots of people don't know they do that...). (oh, you guys who think this stuff is easy while we're at it, go ahead and, fresh from scratch, calculate how many seconds UTC epoc (since Jan 1970) it is to get to the "third sunday of march".)
Oh, and as for whiz-bang DST / TZ libraries? They should try doing all this on a client-side html5 app where all you have is raw javascript that has access to none of that. Yes, we do actually have situations where we need to code to this stuff straight out because whiz-bang DST/TZ library doesn't exist for our platform. date.js is good, but isn't perfect (like the regular javascript Date, it sucks trying to deal with timezones outside of what the browser thinks it is in) and hasn't been updated for useful stuff like this since it came out almost 10 years ago. node.js servers can make system-level calls for some of this, but a browser has no such benefit.
I only brought up the damn 2038 thing as an aside. For crying out loud the comment about it was in parenthesis. Sheesh...
I have been talking about DST, and the DST change, and what it takes for a software firm to deal with it, and why each firm has to deal with it even if for the most part they get their DST information from patches from systems software vendors. And my primary damn point, which is that when companies have to test and track their software to systems software updates that do (or don't) correctly give them the DST information they need for the timezones they care about, that is money spent, and when the government arbitrarily changed it because they have no idea how much work it really took for people like me to figure out what the impacts of it will be on our systems, that was money wasted.
DST and TZ data is closely interrelated - when we changed, others didn't.
I know what the hell I've been talking about here, thank you.
you have absolutely utterly failed to see the point. you have absolutely no idea - i was talking ABSOLUTELY about macro-econ, not micro. at the micro-econ level, it is just money spent.
at the macro-econ level, it is money spent that *provided no value*. Everybody was $5 billion less than they had before, but the products were, in effect, merely the same as they were before all this effort. Nothing was gained. Intellectual and economic power was wasted.
there is a difference, regardless of if you care to see it or not (so far, you don't).
The point is that from the perspective of the company having to pay members of their IT department to work on the DST change, that money was going into an effort that would not, directly, lead to increased sales, increased profits, or increased interest from a marketing standpoint.
It is wasted money.
In the case of the major vendors, they had to do this effectively for every client they had even if they didn't have a support contract to do so. Their support teams "lost" money doing this work, relative to the number of customers that benefitted from the change.
This is in contrast to spending money making a new feature, or fixing REAL bugs, things that actually can increase sales. Billions were spent just to keep working at all, because of the ignorant decisions of lawmakers who have no idea how computers work.
You can try to look at it as the sense of, "well, those IT guys like you spent that income anyways", but that misses the point: when I create something for my company, that is in effect *inventing* money - I increase the value of my company's product, who in turn increase the value of the companies that purchase it by leading them to cost savings and increased profits which get invested etc etc etc. This is the economic power of Intellectual invention, it is why the whole system works (and why IT companies do so well in the stock market - it isn't a limited resource like how much coal there might happen to be under some mountain somewhere).
When that money is spent just to keep something functioning at all, there is no value added, only money lost. The stock market reflected that loss at the time with flatlined growth for almost four months 'til it could recover again. Nobody had any profits to feed into the market after that.
It wasn't $5b per year - it was $5b as a one-time expense. There's nothing more to do now that it is done (and admittedly most platforms made their systems more flexible so they could adapt to other changes, like Russia's DST-365, with much less effort on implementation and testing).
It is unrelated to the supposed claim of $2b per year in "lost productivity", whatever that means (translation: any discussion of 'productivity' requires defining what you mean by it, and nobody can agree on that when it comes to IT work).
never said they weren't. I just said that if you ask the corporate IT world to go through this hell of trying to update systems to reflect a large-scale American change all over again, they'll laugh at you...and give their 527 PAC money to your opponents in an instant, ensuring you'll be kicked out of office.
Slashdot Mirror
Just find a personal itch to scratch and scratch it.
Doesn't have to be something you'll release, but being able to show it in action is an interview booster (thus, if it is mobile, all the better). The fun part is that once it is scratched and you decide to move it somewhere else into the cloud for more permanent hosting, there's another itch to scratch.
Case in point, I put together a shopping list manager using node/express/mongo and jquery/jquery mobile/stativus. Then found that if I were to deploy it at my webhost, I don't have mongo so I then needed to learn an ORM system for node to mysql (using bookshelf js right now). Similarly if you build something in mongo, you can look to learning AWS or Google Cloud Development and get the app out there and there's another skill on the resume checklist.
In fact, doing the database port actually helped me develop and refine unit testing so my data-access layers had the same front API - knowing you're replacing a single piece actually encourages writing the pieces to be more modular and independent.
All javascript, plenty of html5 modern architecture skills learned or refined, and this from someone who spent most of the mid-late 2000s as a J2EE w/ Oracle guru.
So really, the short answer is: just do it.
...when it is religion itself that is causing you stress?
In addition to "all of the above", the other contribution is that of the philosophical equivalent of Heisenberg: the predictions of outbreaks may have increased vaccination usage in the areas involved, which of course will have an effect of downplaying the outbreaks in those areas.
Not saying I have any evidence for that, (and I will wager it unlikely, considering the #s who vaccinate is still far lower than it should be), but a correlation study may be interesting to see.
If the point of knowledge of a possible outcome is to act to deter it, then shouldn't the actions that attempt to deter it be taken into account?
heh. I do wonder if their use of these is considered 'fair use' or if, like in the case of the Obfuscated C entry, it really is a copyright violation and the coders should get compensated? :)
I'm inclined to agree - "malaise" is an opinion, seen better from the outside than within. Ask any social commentator to look at today's workers or kids, with how much they 'veg' in front of a TV or on a computer, and you definitely know that the work itself, with the rare exception, is not in any way fulfilling.
He was right in that automation doesn't necessarily lead to total unemployment: it changes the jobs, and within a company it reduces them, but on the whole we've more jobs now than we did then (as we have more than twice as many people, but close to the same employment rate as we did then), so the system adapts to unemployment, eventually.
I don't think he was using the term 'spiritually' to in any way imply any aspect of religion, so those that interpret it that way are misreading him.
perhaps true...but then I wasn't coding on a laptop in the 4x3 era. :)
and even so, I still live in alt-tab hell because a laptop screen, no matter that it is 1440x900, can't get me my code, my web browser large enough to see the space I'm fixing, and the firebug console to figure out what the bleep is wrong with it, all at the same time.
gimme that thunderbolt...
all that said, the idea of very small pixels on a laptop-sized screen doesn't necessarily make things more readable. For a tablet where you can use vertical orientation to read, it might be better, but on a laptop that is fixed horizontal orientation, I can't see it being that much use for text, and while it may render a blue-ray more accurately, your eyes won't know the difference at that size.
(oh, and in addition to fixing it, I have a thunderbolt monitor for my mac laptop at work, and an imac with a larger screen ratio, too...and i've yet to meet a mac developer who wants to go back to a mere 1080 after finally getting a screen with serious real estate like that.)
I fixed it. I said I fixed it for myself: I have one monitor in vertical orientation. I also shrunk my font size down to 7 point. Seems to work, I can generally get most of a file on the screen at once.
why did it not catch on? Because the display was horrendously expensive since it was so mostly unique, compared to CRT components for 4x3 screens that were extremely cheap and off-the-shelf. It had nothing to do with coder preference at the time and EVERYTHING to do with how much a corporation was willing to spend on its coders. As such, few outside of Xerox even got to try it. Nobody knew what they were missing, because everybody knew it, "wasn't that difficult to work around".
Still, maybe someday it might be nice to have better options and better designs out there instead of stuff that "isn't that difficult to work around." Coding and building the right thing (or a more flexible thing but with better default settings) should be inherent in interface design, but it still isn't, because coders like you seem to be just fine with stuff that "isn't that difficult to work around."
Because of entertainment sources, laptops and desktop monitors are all wide-screen 16x9... ...but that resolution ONLY works for entertainment video. Reading requires vertical height and narrow width (books are the shape they are for a reason), so the more horizontal space that is given at the loss of vertical, the less comfortable reading and writing (and *coding*) are because one can't fit enough vertical lines on the page to be able to speed-scan for context, and at other times someone doesn't bother to limit their readable space width (or it is a plain text file) and so the horizontal line goes well beyond the comfortable 10-12 word limit.
In short, it just doesn't work when the medium is text. (Say what you will about the coming illiterate age at this point...)
1080 is actually very uncomfortable for those of us who were coding in 1440x1280 4x3's prior to the HDMI standard locking us all down to 1080. I personally keep an external monitor rotated 90degrees in order to have a decent working space, separate from my "entertainment" and browsing space.
Who else had a long vertical orientation to the monitor, knowing it was a better way to work? Xerox PARC.
(and gee, many of our problems in Education go away when one addresses the poverty issue that makes education impossible rather than constantly trying to change the education system that has otherwise worked for generations)
So long as we just focus on *treatment* of the sick, costs will continue to spiral.
A general influx of cash doesn't just focus on treatment of those sick - it starts to alleviate the issues that allow disease to spread in the first place (lack of hygene, lack of vaccination, lack of clean water, lack of balanced food (and complete meals), and lack of general preventive care, and lack of birth control - ALL things people in poverty already lack).
Health care costs get under control when the focus is on prevention rather than treatment: you spend FAR less money when fewer people get sick. When you use the capital to address the causes of disease rather than just treating it, you spend much less on treating the ones that got away.
Relatedly, this is why insurance companies love birth control - a pill a day and a box full of condoms is far cheaper to them than the thousands of dollars for examinations, the birth, emergency natal care, and having to cover the kid for the next 26 years.
Recent obnoxious examples include Facebook (the one bundled with my phone was 9meg. The current is 34m + almost as much data memory used up), and Amazon's app store (a 5 meg app that brings in more than 17 and sometimes as high as 49 meg tagged *data*, not cache).
I dropped amazon from my phone (an older HTC Evo, so it only has 160 meg or so for app+data) because of this, and just gave up on those apps I'd purchased through it (some of which were on google play). Even so, any time I need to update FB, I generally have to wipe the data out to make room for the download.
Sheesh...
when the tulips start to bloom again.
College ain't supposed to be easy.
In CS, the killer is usually electro-magnatism or calculus-level probability.
In Physics, it is usually diff-eq's.
In math, it is usually partial diff-eq's.
Yes, the exceptions to the "rules" in org-chem is maddening...but if it wasn't, prescriptions and pharmaceuticals would be easy. Instead, they are rife with mistakes, side effects, false-positives, and a lot worse, and if you don't have the background to understand at least to a degree why, then I'll be damned before I let you write me a prescription for anything.
But seriously, this is college leading to one of the toughest post-grad programs our society has to offer. It is supposed to be hard. Deal with it or get out.
you really don't get it. money spent on a product that adds no value to the product is money lost.
if you don't get that simple *fact*, I'm not going to bother to say anything anymore.
Which was my point, I thought I made clear, from the very beginning. Keeping up with software updates (that theoretically aren't supposed to change anything unless they make it better, even if it means an API difference to code to) is one thing. Generally, one can hold back a patch and coordinate it with some other release cycle.
Having to adapt to an arbitrary, non-technical reason mandated by a clueless government is something else, a very EXPENSIVE, something else, as it is as i noted, something that adds no value to the product but costs as much as a new large feature would. And in this case, the deadline wasn't set by us either, but by the same government - we couldn't hold the patches back. Quite the opposite, we needed to get them in and tested ASAP as customers using our app to project into the future needed to have that date information accurate.
My response (see the title this thread has had all along) was in response to the continual suggestions that happen twice a year, every year, right on schedule, for getting rid of DST, but clueless dolts who think it is "easy" to do and wouldn't have any impact except some alleged positive one based on some analyst's arbitrary definition of "productivity". While getting rid of DST might eventually have a long term benefit, it will still have an expensive short-term cost that needs to be carefully considered based on the experiences of 2005-2007.
Just having some database isn't enough in and of itself. One needs to be able to process it and interpret it correctly so that it "makes sense" to the business model one is using.
In addition, code that looks backwards in time (reporting engines, for example, or event history viewers) need to be able to use the old rules as they look back, while looking at the current (and potentially new) rules looking forward, and have to know at what year/date some country made the decision to cut DST. This is a reason the TZ folder/file on linux boxes (for example) is as large as it is.
No, we're not mission-critical like medical stuff, but that doesn't stop the customer base from griping when the DST-handling code was broken before I was assigned to fix it.
And this DST issue is somewhat different from what I was originally ranting about, which was the amount of work I was going through building test plans and cases for actually being able to see if the software I was working on at the time handles the DST change correctly, coordinating and tracking all of the OS and software patches (there were 10 updates to Java's JDK/JVM alone in a matter of 5 weeks, ALL related to this issue) and ensuring our stuff would work.
It isn't the best at all. I inherited this API. Trying to see if we can take the pressure off by having the API send a date-time string back instead of making the UI responsible for the epoc conversion, so the server (with much better resources) becomes responsible for it. As it is a published API for our customers to also use, it is a pretty big change to do that.
That said, I've been rather proud of what I've managed to achieve so far with the limited resources I've got.
THANK YOU! somebody else actually 'got it'.
Currently I am having to track and get our system up to date for several other countries timezones that have changed their DST rules in the last 5 years, like Iraq and Egypt (both dropped DST entirely), plus trying to figure out, without actually coding a lunar calendar into my system, when Brazil postpones their DST end date by a week to avoid closing Carnivale early (yeah, lots of people don't know they do that...). (oh, you guys who think this stuff is easy while we're at it, go ahead and, fresh from scratch, calculate how many seconds UTC epoc (since Jan 1970) it is to get to the "third sunday of march".)
Oh, and as for whiz-bang DST / TZ libraries? They should try doing all this on a client-side html5 app where all you have is raw javascript that has access to none of that. Yes, we do actually have situations where we need to code to this stuff straight out because whiz-bang DST/TZ library doesn't exist for our platform. date.js is good, but isn't perfect (like the regular javascript Date, it sucks trying to deal with timezones outside of what the browser thinks it is in) and hasn't been updated for useful stuff like this since it came out almost 10 years ago. node.js servers can make system-level calls for some of this, but a browser has no such benefit.
I only brought up the damn 2038 thing as an aside. For crying out loud the comment about it was in parenthesis. Sheesh...
I have been talking about DST, and the DST change, and what it takes for a software firm to deal with it, and why each firm has to deal with it even if for the most part they get their DST information from patches from systems software vendors. And my primary damn point, which is that when companies have to test and track their software to systems software updates that do (or don't) correctly give them the DST information they need for the timezones they care about, that is money spent, and when the government arbitrarily changed it because they have no idea how much work it really took for people like me to figure out what the impacts of it will be on our systems, that was money wasted.
DST and TZ data is closely interrelated - when we changed, others didn't.
I know what the hell I've been talking about here, thank you.
you have absolutely utterly failed to see the point. you have absolutely no idea - i was talking ABSOLUTELY about macro-econ, not micro. at the micro-econ level, it is just money spent.
at the macro-econ level, it is money spent that *provided no value*. Everybody was $5 billion less than they had before, but the products were, in effect, merely the same as they were before all this effort. Nothing was gained. Intellectual and economic power was wasted.
there is a difference, regardless of if you care to see it or not (so far, you don't).
The point is that from the perspective of the company having to pay members of their IT department to work on the DST change, that money was going into an effort that would not, directly, lead to increased sales, increased profits, or increased interest from a marketing standpoint.
It is wasted money.
In the case of the major vendors, they had to do this effectively for every client they had even if they didn't have a support contract to do so. Their support teams "lost" money doing this work, relative to the number of customers that benefitted from the change.
This is in contrast to spending money making a new feature, or fixing REAL bugs, things that actually can increase sales. Billions were spent just to keep working at all, because of the ignorant decisions of lawmakers who have no idea how computers work.
You can try to look at it as the sense of, "well, those IT guys like you spent that income anyways", but that misses the point: when I create something for my company, that is in effect *inventing* money - I increase the value of my company's product, who in turn increase the value of the companies that purchase it by leading them to cost savings and increased profits which get invested etc etc etc. This is the economic power of Intellectual invention, it is why the whole system works (and why IT companies do so well in the stock market - it isn't a limited resource like how much coal there might happen to be under some mountain somewhere).
When that money is spent just to keep something functioning at all, there is no value added, only money lost. The stock market reflected that loss at the time with flatlined growth for almost four months 'til it could recover again. Nobody had any profits to feed into the market after that.
It wasn't $5b per year - it was $5b as a one-time expense. There's nothing more to do now that it is done (and admittedly most platforms made their systems more flexible so they could adapt to other changes, like Russia's DST-365, with much less effort on implementation and testing).
It is unrelated to the supposed claim of $2b per year in "lost productivity", whatever that means (translation: any discussion of 'productivity' requires defining what you mean by it, and nobody can agree on that when it comes to IT work).
never said they weren't. I just said that if you ask the corporate IT world to go through this hell of trying to update systems to reflect a large-scale American change all over again, they'll laugh at you...and give their 527 PAC money to your opponents in an instant, ensuring you'll be kicked out of office.