As everyone knows, the year 2000 came and nothing happened, but the panic over the 2000 bug provided a livelihood for many computer experts, programmers and computer service providers and caused many organizations a lot of expenses. Maybe we'll learn something for the next bug?
Aryeh Seter
We all heard about Bug 2000 at the time. To remind you - at the time, with the turn of the millennium, many computer experts warned about the expected problem in some computer systems, various processing devices and computerized control systems that have reference to the date. The experts warned that these systems would collapse, or cause damage and malfunctions during the transition to the year 2000. These were relatively old systems, in which, for reasons of saving memory resources that were very expensive at the time of their design, only two digits were assigned to the year. In the transition to the year 2000, which will be marked 00, the experts warned - the systems will go crazy.
As everyone knows, the year 2000 came and nothing happened, but the panic over the 2000 bug provided a livelihood for many computer experts, programmers and computer service providers and caused many organizations a lot of expenses.
At the time we read about other different dates that are prone to calamities for various reasons. We will bring here, seriously or not, two more real bugs that, as far as we know, have not been mentioned. These bugs are supposed to happen, one in 2100 and the other in 2151.
Acceptable digital clocks, which include year, month, day of the month and day of the week - support the calendar, until the year 2100; This is explicitly written in the accompanying material. A similar thing also exists in various devices equipped with a clock and in the operating systems of computers. Why only until 2100? The explanation lies in a leap year, which includes an extra day in February, every four years.
As we know, the reason for the addition of a day to the year, every four years, is that the real year is 365 days plus about a quarter of a day. The addition of the day to February was made so that the seasons would not creep over the years so that August, for example, in the Northern Hemisphere, would be a few hundred years later in the middle of winter - as happens, for example, in the Muslim calendar. In this calendar, the migration of the seasons occurs at a much faster pace because the Muslim calendar is based on a 29- or thirty-day lunar month and it does not observe leap years - an addition of a month every two or three years, as is done in the Hebrew calendar.
But the rule of adding a day to February every four years is not exact - there are rules that deviate from this rule.
A. Every four years - in a year that is divisible by four - a day is added to February.
B. Exception: a year that is divisible by 100, even though it is divisible by four - February remains with 28 days.
third. Exception: A year divisible by 400, although divisible by 100, February lasts 29 days.
The clocks and computers only know Rule A. according to rule c. The year 2000 was normal in terms of the clock, but on 1.3.2100, the clock will show 29.3 because it does not know Rule B.
Do you think it is possible to solve the problem afterwards, simply by moving the clock to the correct date?
Anyone who knows the answer is welcome to write it in a comment. It will be interesting to see who will be the first with the simple answer.
And now for the second bug.
Some time ago, we came across software for managing synagogue activities. This software handles, among other things, holidays, memorial days, bar mitzvah dates. It shows the dates of Israel's holidays and the dates of reading Torah passages. So, for example, you can check when there was or will be a bar mitzvah and on which parshat of Shabbat, and more kahana and kahana. This software naturally includes a Hebrew and general calendar as a central component. Since the software was written in the 2000s and since it was designed to also respond to dates that exceed the limits of the century - it was assigned four digits to mark the general year and of course four letters to mark the Hebrew year. Therefore, the XNUMX bug was not at all relevant to this software.
As you know, the Hebrew year is marked with letters. Each Hebrew letter has a numerical value and the combination of the letters gives the desired number. Today we are in the year 400. A = 300, S = 60, S = 5, E = 765, together 1000. The complete Hebrew year notation also includes a letter for the thousands (5,765). This letter is marked with a dash. The current year is therefore 1640, that is, 9 for the creation of the world according to the Jewish faith. The thousand letter is usually omitted. After this omission, the Hebrew year can be marked with one letter (for example, 1940 was the year of T), or two letters (for example, the 9 years after T, or the year XNUMX), or three letters (for example, the XNUMX years after T Q, or the year XNUMX which was several years ago), or four letters - as we are usually used to.
The synagogue software we mentioned supports, as mentioned, a foreign year in a four-digit format and a Hebrew year up to four letters. But in the year 2151, the Hebrew year will be a year of five letters. After all, you have a bug. Even if the Messiah comes before then, it will not solve the problem that users of this version of the software will have in nearly 150 years.
And by the way - the synagogue's software ran under the DOS operating system - like many business management programs that operate in the DOS format successfully, including some that were written recently. At the time, we heard from the developer of the software that he was looking to turn it into a Windows version - and you have a topic of secularization.
And it reminds us of the old joke about girls working in Bnei Brak under Doss and in Amsterdam under Windows.
Holidays for everyone!
One response
LOL