| Computing desk | ||
|---|---|---|
| < May 12 | << Apr | May | Jun >> | May 14 > |
| Welcome to the Wikipedia Computing Reference Desk Archives |
|---|
| The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages. |
May 13 Information
In a discussion on the Mathematics desk which archived yesterday @ Dionne Court: said:
Compact arithmetic methods of producing calendars, calculating the days between 2 dates, etc., have been used in digital computers ever since there have been digital computers.
So they know the number of days in each month, but the programmers don't always get it right (hence the "millennium bug" partly caused by some computers not knowing that February 2000 had 29 days, although they knew that (say) February 1900 and February 2100 have only 28). How is the information programmed into computers?
Topical aside (which always generates heated discussion): the day of the week on which the thirteenth of the month most often falls is ... Friday. 89.240.119.222 ( talk) 09:23, 13 May 2022 (UTC)
- The millenium bug was primarily about the use of two-digit years in the 1900s. Separately, leap year calculation is basically an if statement based on the year. Commonly, it is set up as a series of logical comparisons, but it can be programmed many different ways. Example:
- Leap = Year%4==0 && (Year%100!=0 || Year%400==0)
- Many programmers didn't know about the third rule and simply didn't write it into their programs. 97.82.165.112 ( talk) 09:55, 13 May 2022 (UTC)
- There is more than one algorithm. When I needed to program a calculation of days between 2 dates, back in the 1970's, I didn't bother about Feb 29 2000. I certainly knew about it - learnt all about the leap day system in primary school. Hence I potentially contributed to the millennium bug, along with many others - but I doubt my software was in use long enough. You are right with the the word "partly". Most millennium bugs were not due to algorithm deficiencies but to compact storage. Typically internal storage of dates was and is in the form of seconds starting from midnight on an arbitrary date already gone when the software was developed. Hence date rollback would occur whenever all bits in the date storage words became 1 (or 0), not necessarily in Year 2000 or any other year. And it can still happen.
- I remember being asked by ignorant company management to stay on duty over midnight December 31 1999 in case something bad happened. Nothing happened of course, but I got paid double time. I had told them and told them there would be no problem and explained why, but they replied they had to inform the stock exchange that they had it under control, and that meant having me on standby. What a joke!
Dionne Court (
talk) 10:08, 13 May 2022 (UTC)
- "And it can still happen" - yes. On the 1 January 2022, Microsoft's Exchange Server 2016 and Exchange Server 2019 hiccoughed when they attempted to store a character string in an integer field, and the "22" was out of range. Look out for Y38K when 32-bit UNIX systems will time travel back to 1901. 2079 is another roll-over bug, and the leap-year problem is expected back in 2100. OK, few readers of this will be around then, but if somehow life is prolonged until 2137 the current GPS implementation will crash. 2262 will cause some 64-bit systems that use nano-second counting to fail. Then there's the whole issue of 10,000 busting all displays. There are plenty of others all the way up to when 64-bit seconds precision counters fail in 292,277,026,596 AD.
Martin of Sheffield (
talk) 10:50, 13 May 2022 (UTC)
- ( edit conflict) The company I worked for, also quoted on the stock exchange, was taken over in 1999. The purchasers refused to sign the contract until after the New Year, and the managing director worked alone over the bank holiday monitoring the systems. He was a lucky man - during a move a heavy machine had to be hoisted out of the basement. The sling broke and it crashed to the floor on the spot he had been occupying seconds earlier. A cartoon on the wall of the computer room immortalised the time when this machine had mysteriously stopped working. He worked day and night for several days taking it apart and putting it together but was unable to fix it. Then he noticed it wasn't plugged in.
- That program you quoted tells the computer which years are leap years, but how is the computer told the number of days in February of a leap year or (come to that) the number of days in January, March, April, May, June, July, August, September, October, November and December? 89.240.119.222 ( talk) 11:06, 13 May 2022 (UTC)
- "And it can still happen" - yes. On the 1 January 2022, Microsoft's Exchange Server 2016 and Exchange Server 2019 hiccoughed when they attempted to store a character string in an integer field, and the "22" was out of range. Look out for Y38K when 32-bit UNIX systems will time travel back to 1901. 2079 is another roll-over bug, and the leap-year problem is expected back in 2100. OK, few readers of this will be around then, but if somehow life is prolonged until 2137 the current GPS implementation will crash. 2262 will cause some 64-bit systems that use nano-second counting to fail. Then there's the whole issue of 10,000 busting all displays. There are plenty of others all the way up to when 64-bit seconds precision counters fail in 292,277,026,596 AD.
Martin of Sheffield (
talk) 10:50, 13 May 2022 (UTC)
- Famously,
Lotus 1-2-3 didn't know that February 1900 only had 28 days: a mistake that was
copied by
Microsoft Excel for reasons of compatibility.
AndrewWTaylor (
talk) 13:14, 13 May 2022 (UTC)
- There is an algorithm which gives the correct number of days in all the months all the time with no exceptions for leap years or anything else. It was devised by the Open University in 1998 and copied to the archived discussion referred to at the beginning of this section. However, nobody seems to know about it! For example [1] where a programmer attempted to write one and failed. Discussion forums are equally in the dark [2]. [3] is another example of a programmer who challenged himself to create such a formula and failed. The following extract from a letter from a don at the university dated 21 February 1998 may be of interest:
While doing some computer programming I needed to determine an upper bound for the number of days in a month and I sought amusement in trying to find a one-liner to do the job, using only well-known functions.
First I thought of representing the function d(m) -> {31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31} as a Fourier series but that turned out to be rather complicated and I eventually realised that I could achieve what I wanted by something like a mean term 30.5 and a single trigonometric function. I took August as the starting point; hence the phase of 7.5. For some reason this turned out better than January, although both are second of consecutive 31-day months. The fine tuning was determined by experiment. Thus 30.5 became 30.9 with a multiplier of 2.9, which is quite near to 11π/12.
The bit in square brackets was a later enhancement to deal with leap years.
- We have an article about the
year 2000 problem, whose lead contains:
In the years leading up to the turn of the century, the public gradually became aware of the "Y2K scare", and individual companies predicted the global damage caused by the bug would require anything between $400 million and $600 billion to rectify. (...) Contrary to public expectations, few major errors actually occurred in 2000.
- Regarding the actual question: no sane experienced programmer should ever program their own "how many days between two dates" function. They should pull it from language libraries, which are designed, coded, and tested by date geeks as a whole project, rather than half-baked as a mini-part of a larger project. Here’s the source code for the Python library, for instance.
- (Of course, there are many programmers that are inexperienced or insane, and the results can be found via the online search
date site:thedailywtf.com.) Tigraan Click here for my talk page ("private" contact) 09:07, 18 May 2022 (UTC)
| Computing desk | ||
|---|---|---|
| < May 12 | << Apr | May | Jun >> | May 14 > |
| Welcome to the Wikipedia Computing Reference Desk Archives |
|---|
| The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages. |
May 13 Information
In a discussion on the Mathematics desk which archived yesterday @ Dionne Court: said:
Compact arithmetic methods of producing calendars, calculating the days between 2 dates, etc., have been used in digital computers ever since there have been digital computers.
So they know the number of days in each month, but the programmers don't always get it right (hence the "millennium bug" partly caused by some computers not knowing that February 2000 had 29 days, although they knew that (say) February 1900 and February 2100 have only 28). How is the information programmed into computers?
Topical aside (which always generates heated discussion): the day of the week on which the thirteenth of the month most often falls is ... Friday. 89.240.119.222 ( talk) 09:23, 13 May 2022 (UTC)
- The millenium bug was primarily about the use of two-digit years in the 1900s. Separately, leap year calculation is basically an if statement based on the year. Commonly, it is set up as a series of logical comparisons, but it can be programmed many different ways. Example:
- Leap = Year%4==0 && (Year%100!=0 || Year%400==0)
- Many programmers didn't know about the third rule and simply didn't write it into their programs. 97.82.165.112 ( talk) 09:55, 13 May 2022 (UTC)
- There is more than one algorithm. When I needed to program a calculation of days between 2 dates, back in the 1970's, I didn't bother about Feb 29 2000. I certainly knew about it - learnt all about the leap day system in primary school. Hence I potentially contributed to the millennium bug, along with many others - but I doubt my software was in use long enough. You are right with the the word "partly". Most millennium bugs were not due to algorithm deficiencies but to compact storage. Typically internal storage of dates was and is in the form of seconds starting from midnight on an arbitrary date already gone when the software was developed. Hence date rollback would occur whenever all bits in the date storage words became 1 (or 0), not necessarily in Year 2000 or any other year. And it can still happen.
- I remember being asked by ignorant company management to stay on duty over midnight December 31 1999 in case something bad happened. Nothing happened of course, but I got paid double time. I had told them and told them there would be no problem and explained why, but they replied they had to inform the stock exchange that they had it under control, and that meant having me on standby. What a joke!
Dionne Court (
talk) 10:08, 13 May 2022 (UTC)
- "And it can still happen" - yes. On the 1 January 2022, Microsoft's Exchange Server 2016 and Exchange Server 2019 hiccoughed when they attempted to store a character string in an integer field, and the "22" was out of range. Look out for Y38K when 32-bit UNIX systems will time travel back to 1901. 2079 is another roll-over bug, and the leap-year problem is expected back in 2100. OK, few readers of this will be around then, but if somehow life is prolonged until 2137 the current GPS implementation will crash. 2262 will cause some 64-bit systems that use nano-second counting to fail. Then there's the whole issue of 10,000 busting all displays. There are plenty of others all the way up to when 64-bit seconds precision counters fail in 292,277,026,596 AD.
Martin of Sheffield (
talk) 10:50, 13 May 2022 (UTC)
- ( edit conflict) The company I worked for, also quoted on the stock exchange, was taken over in 1999. The purchasers refused to sign the contract until after the New Year, and the managing director worked alone over the bank holiday monitoring the systems. He was a lucky man - during a move a heavy machine had to be hoisted out of the basement. The sling broke and it crashed to the floor on the spot he had been occupying seconds earlier. A cartoon on the wall of the computer room immortalised the time when this machine had mysteriously stopped working. He worked day and night for several days taking it apart and putting it together but was unable to fix it. Then he noticed it wasn't plugged in.
- That program you quoted tells the computer which years are leap years, but how is the computer told the number of days in February of a leap year or (come to that) the number of days in January, March, April, May, June, July, August, September, October, November and December? 89.240.119.222 ( talk) 11:06, 13 May 2022 (UTC)
- "And it can still happen" - yes. On the 1 January 2022, Microsoft's Exchange Server 2016 and Exchange Server 2019 hiccoughed when they attempted to store a character string in an integer field, and the "22" was out of range. Look out for Y38K when 32-bit UNIX systems will time travel back to 1901. 2079 is another roll-over bug, and the leap-year problem is expected back in 2100. OK, few readers of this will be around then, but if somehow life is prolonged until 2137 the current GPS implementation will crash. 2262 will cause some 64-bit systems that use nano-second counting to fail. Then there's the whole issue of 10,000 busting all displays. There are plenty of others all the way up to when 64-bit seconds precision counters fail in 292,277,026,596 AD.
Martin of Sheffield (
talk) 10:50, 13 May 2022 (UTC)
- Famously,
Lotus 1-2-3 didn't know that February 1900 only had 28 days: a mistake that was
copied by
Microsoft Excel for reasons of compatibility.
AndrewWTaylor (
talk) 13:14, 13 May 2022 (UTC)
- There is an algorithm which gives the correct number of days in all the months all the time with no exceptions for leap years or anything else. It was devised by the Open University in 1998 and copied to the archived discussion referred to at the beginning of this section. However, nobody seems to know about it! For example [1] where a programmer attempted to write one and failed. Discussion forums are equally in the dark [2]. [3] is another example of a programmer who challenged himself to create such a formula and failed. The following extract from a letter from a don at the university dated 21 February 1998 may be of interest:
While doing some computer programming I needed to determine an upper bound for the number of days in a month and I sought amusement in trying to find a one-liner to do the job, using only well-known functions.
First I thought of representing the function d(m) -> {31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31} as a Fourier series but that turned out to be rather complicated and I eventually realised that I could achieve what I wanted by something like a mean term 30.5 and a single trigonometric function. I took August as the starting point; hence the phase of 7.5. For some reason this turned out better than January, although both are second of consecutive 31-day months. The fine tuning was determined by experiment. Thus 30.5 became 30.9 with a multiplier of 2.9, which is quite near to 11π/12.
The bit in square brackets was a later enhancement to deal with leap years.
- We have an article about the
year 2000 problem, whose lead contains:
In the years leading up to the turn of the century, the public gradually became aware of the "Y2K scare", and individual companies predicted the global damage caused by the bug would require anything between $400 million and $600 billion to rectify. (...) Contrary to public expectations, few major errors actually occurred in 2000.
- Regarding the actual question: no sane experienced programmer should ever program their own "how many days between two dates" function. They should pull it from language libraries, which are designed, coded, and tested by date geeks as a whole project, rather than half-baked as a mini-part of a larger project. Here’s the source code for the Python library, for instance.
- (Of course, there are many programmers that are inexperienced or insane, and the results can be found via the online search
date site:thedailywtf.com.) Tigraan Click here for my talk page ("private" contact) 09:07, 18 May 2022 (UTC)