Abandon hope all ye who buy Microsoft
if the 64-bit version of that patch has been installed, Outlook might crash on start-up
They can't even start Outlook now.
Stop us if you've heard this one, but Microsoft has pulled a couple of buggy patches in Office. It also left a crash-worthy Outlook security fix in place. The two non-security patches were part of this month's Patch Tuesday, both for Office 2010. The patches in question were supposed to support Japan's upcoming epochal …
If any other vendor in history demonstrated such incompetence in coding, they would file for Chapter 11 in less than two years.
MS, coasting on a literal mountain of cash, just keeps fucking up and cannot fix things any more.
I wonder how much worse the situation will get, because let's face it, nobody's going to switch to Linux because of this.
"nobody's going to switch to Linux because of this."
Well, with the steady 'drip drip drip' and "froggy in a pot coming to a boil" analogies, there will be a breaking point eventually. Just not now, apparently.
Micro-shaft is simply acting like the MONOPOLY they are. Time for some trust-busting, I say. We'll start with their patent portfolio and licensing practices for new hardware vendors [what I perceive as the 2 major roadblocks to getting a proper windows competitor going].
For starters, ANY OS maker that wants to allow windows applications to install and run, when MS's EULA's *PREVENT* you from doing so legally, has "that" as an automatic roadblock. MS would be able to legally disable functionality or perform poorly ON PURPOSE, "fail to run under Wine", things like that. And refusing to license windows [at reasonable prices] for computer makers that pre-install Linux (or 'dumping' such licenses at unreasonably low prices in special "deals" for computer makers that do NOT have Linux pre-installed, same thing I'd say) is a PREDATORY PRACTICE (identified back in 2006, not sure if they can still get away with this or not). This archived article discusses that, lest we forget.
So the problem is less about Linux, and MORE about "predatory practices" by Micro-shaft, that STIFLE Linux being a major factor in desktop operating systems.
....but you forgot to mention "fashion". In the past M$ had no excuse for never doing any testing, and leaving the testing to the (paying) users. Well...they are still doing this, but now they have an excuse.
Namely -- "agile", "scrum", "devops", etc etc. Today these fashions mean that there isn't a comprehensive requirements statement AGAINST WHICH TO TEST THE PRODUCT.
Of course, the fashionistas will tell us that they "test the patch". I though that excuse had been thoroughly discredited years ago.....but -- hey ho -- we need to remember what Tallyrand said about the Bourbons all those years ago: "They forgot nothing and learned nothing".
isn't one of the problems that the 'local date' will become 1st May 00 after the abdication, whist still being 1st May 2019 in other parts of the computer. That's quite a DST (daylight saving time) offset!
millenium bug all over again, guardian has a fairly accurate article here:
It will be year 1 of the new era, but an additional issue is that the era name hasn't been announced yet and that forms part of the localised date format - for example, this year can be expressed as "平成30", "Heisei 30" or even "H30" depending on the choice of formats offered.
Traditionally the era name is is not announced until after accession, but this time it is expected to be announced before to give companies a chance to change things. Apparently though a new era can be added to Japanese versions of Windows with a simple registry update, so what could possibly go wrong with that?
Or also with a specific Unicode point. For example, 平成 has its own "hangaku" (half-width) rendering that squashes the two characters together: ㍻
I read somewhere (NHK News?) that even getting the new character into the official Unicode list is not trivial and it may not even be possible to complete until a while after. And then, all those OS updates for all those devices out there...
The most pragmatic solution (for programmers and the like) is to just pretend that it's still the 平成 era for a while, then go through a period where these non-existent dates coexist with implementations of the new naming. Quite a lot of work and scope for problems, but not quite as bad as a Y2k-style counter overflow problem.
isn't one of the problems that the 'local date' will become 1st May 00 after the abdication, whist still being 1st May 2019 in other parts of the computer.
If it's implemented properly the underlying system clock will still run on something like UTC, and only the presentation of the date/time will change, so it should have minimal effect on system operation, just like DST.
Previous Windows versions maintained the system clock in local time, but I thought they'd got that right from W7, if not before?
If it's implemented properly
Ah, the triumph of hope over experience.
Remember that this is the Microsoft who haven't been able to internationalise the date and time format used in SharePoint's Central Admin even after four full version releases over the span of ten years.
Any application that internally uses the calendar for datetime is badly coded. UNIX time is what any correctly coded application should be using, and then use a library to translate that datetime into the users calendar when it needs to be displayed.
@Spazurtle re UNIX time. ... that's great ..... until 2038.
Everything will stop working in 2038.
Only if using 32-bit time fields based on seconds since the epoch. A 64-bit time field would be fine.
I interpreted the statement about UNIX time as meaning the use of an internal date/time representation based on elapsed number of seconds (or smaller units if necessary) since a specific point, which need not be the same representation shown to the user. Regardless of how the timestamp is stored, it's just a matter of how the date/time is rendered when displaying it to the user. Someone with a Japanese locale might see a different date output from someone in the US, for example.
Of course I don't know how Microsoft are handling this internally so perhaps they're using a different approach. Or maybe a few different approaches have sneaked into their codebase over time and now they have to fix a load of different code paths to make them consistently handle the new era. I can only speculate as to why it seems to be tricky.
"As ever, programmers have to deal with flaws in the real world. One of those flaws is that user facing code mostly has to use the times and dates that people use."
Which is why I said to use a library to translate the internal time to the user's calendar when it needs to be displayed to the user.
@Spazurtle re UNIX time. ... that's great ..... until 2038.
Everything will stop working in 2038.
There was stuff calculating expiry dates that stopped working on the 19th of January 2018 and there will also be stuff stopping working on the 19th of January 2023.
I'd like to say that hopefully this will concentrate a few minds, in our case the great minds decided to knock five years off the expiry date and 'we'll get round to fixing it sometime in the next five years' (by which time we'll run into it once again and everyone will be surprised once again).
I think python already has Unix time as a floating point number...
Bah. For real future-proofing, they should be representing it as a complex number. Anyone who's worked in a large organization knows that imaginary time is often just as important as real time.
There really are politicians out there that are already legislating to make everyday life easier for machines.
They are legislating to make it easier to identify people, Computers are just the tool to do that. It's making it easier for them to file, index, stamp etc. everyone so when they have to pull your file for investigation they are not misled by instead having someone elses file.
Downvoted, because I was exactly pointing out incompetent designs where software can't cope with what people are used and you can't change easily. Was it so difficult to understand?
Just like people who want to use just ASCII7 ignoring the needs of many languages which are not English.
The words from the world of the non-coders--ignorant as ever.
An intelligent individual recommends thoughtful solutions.
A fool talks down to others without any conscious thought or insight--obviously, because they have none.
You did accomplish something; since we can now say, we know more about you than you know about compilers.
It doesn't help, though, that the government has yet to announce what the new era is going to be called, so they can't even begin the process of requesting a Unicode update!
No-one should be storing dates in as Heisei nn, but I wouldn't put it past Japanese programmers to have actually done so. Finally, official documents cannot continue to use Heisei 31 as a workaround as that will not be correct.
<iNo-one should be storing dates in as Heisei nn, but I wouldn't put it past Japanese programmers to have actually done so.</i>
Yes, and even if no one were storing dates in Heisei form, there would be applications which process documents using that form. There will be a need to handle Heisei dates, including incorrect ones (H31 and later). Badly-formed inputs are a fact of life.
Having lived and worked in Japan I can tell you that their local calendar system is just mental - no-one in their right mind uses it. The emperor’s first task should be to persuade the Japanese to bring their calendar system into the 21st century. Seriously it’s so bad that normal business people can’t cope, never mind the customers.
Biting the hand that feeds IT © 1998–2019