Due on 24/01/22, that’s 24th January 2022 for you guys.
I expect good results, Epyc and Threadrippers > 32 cores are well out of my price range, so I expect AMD are minting it, especially if they can’t be bothered to offer something to tempt me. No blame attached, I understand AMD need to make as much money as they can. Still happy with my 3950x’s though.
Does anyone think that the AMD price nervousness on the markets is a worry about results?
Does anyone think that the AMD price nervousness on the markets is a worry about results?
Not this quarter… they will be great. I think the nervousness is more about the long term. AMD is priced for a pretty bright future… and there are many clouds on the horizon.
Alan
Lots of us use DD/MM/YYYY on this side of the pond. It makes for less code in sorting by date by going from smallest time interval to largest. But even that failed when calculating escrows, because we needed to count the days. Thus we used an embedded MSDOS/Windows Julian date (all the days from 01/01/1900 until the date(s) in question, and subtract the older from the newer to get the day count. The Y2K bug was because Micro$oft flubbed leap year calculations on 01/01/2020 (no leap day every 400 years). I reported it to them in ~1983 when I ran a test 30 year escrow that ended in 2013 and it failed. That may have been the earliest detected Y2K issue, and Microsoft ignored the report. It took me two lines of code to fix the problem so it would have been trivial for M$ to start rolling out fixes earlier. There are good reasons why I hate Micro$oft.
BTW, my latest complaint is that I cannot set ethernet as a metered connection and Heroes of the Storm introduced a bug that kills my Wifi connection the first game of Heroes. So I have to leave the ethernet plugged in and get loads of updates I hate because now I could accidentally upgrade to Windows 11 and M$ insists on showing me ads every three days they call the tour of new Windows 10 features. I also have to pay attention to turn Chrome back as my default browser (for some of the security extensions Edge lacks). No, I am not willing to believe Edge is more secure.
Fool on,
Roleplayer
FWIW, upgraded to win 11 and it appears to work just like 10 for the things I do, but supposedly more secure. I have no problems keeping Chrome as the browser.
Alan
Roleplayer,
Just teasing about DD/MM/YYYY format, ascending or descending significance makes more sense imho. Though YYYY/MM/DD sorts perfectly it’s more difficult to say in words without using “in the year of”. I suspect MM/DD/YYYY was born of a revolutionary desire to be different though January 13th 2022 rolls of the tongue easier.
The Y2K bug was because Micro$oft flubbed leap year calculations on 01/01/2020 (no leap day every 400 years).
Back to the future? Odd how the Y2K bug was caused by something 20 years in the future.
Also weird that “the” Y2K bug was caused by Microsoft when lots of the offending (probably) Cobol code was written before Microsoft was business, I would think.
IIRC to recap:
Thus, about 365.24…days per year according
Mike
Part of mu job at MITRE was providing software for Y2K, and dealing with the various “doom dates” and providing software to covert between multiple calendars. First, let me make a slight correction to Mike. The year 2000 was the first time anyone had to deal with a 400 year multiple being a leap year. But there is another ‘adjustment’ needed. Originally the plan was for the year 15000 to not be a leap year. More recently the choice has been either 3000 or 4000 not being a leap year. My guess is it will be 4000. Will 8000 also be not a leap year? In any case, plenty of time to get ready. Why is this not already fixed? You are probably aware of leap seconds added to, or subtracted from the clock to keep the day aligned with International Atomic Time (TAI, blame the French for the backward TLA.). It may be that enough leap seconds are subtracted that there is no need for further corrections.
But there are two doom dates that most of us will live through. The first is the DOS doom date, which is actually the FAT16 doom date. FAT32 is fine, but FAT16 runs out of life on December 31, 2027. So if you have any old thumb drives, or hard disks which still have FAT16 file systems. It is about time to copy the data off. Switching to unsigned won’t fix it. There really are only 7 bits for the date in FAT16.
What about Unix and Linux? The Unix doom date is January 19, 2038–for 32-bit computers. There is an easy fix, and I suspect any remaining 32-bit Unix OSes have defined the time as a 32-bit unsigned integer. That gets you out to 7 February 2106. AFAIK this is only required for some 386 flavors of Unix. Again, AFAIK all Linux versions use 64-bit clocks. (Yes, the time_t is 64-bits, but somewhere in the hardware is a real-time clock chip. Just because it returns a 64-bit time, doesn’t mean that the chip uses 64-bits internally. Some older RTC chips used 40 or 48 bits. Not worth testing for. 
So if you have any old thumb drives, or hard disks which still have FAT16 file systems. It is about time to copy the data off.
Has anyone proven that you can’t copy the data off of those FAT16 drives? Or just that you can’t write a new directory entry?
I would think that you could just change your system date to read the drive, if required.
Mike
…but FAT16 runs out of life on December 31, 2027.
FAT16 is good until 2108. The 7-bit year (0-127) is added to the base year of 1980.
Y2K wasn’t about a leap year. It concerned the standard practice of only storing the two digit year. Was “00” either 1900 or 2000? Was “00” < “99”?
https://en.wikipedia.org/wiki/Time_formatting_and_storage_bu…
mschmit wrote:
Back to the future? Odd how the Y2K bug was caused by something 20 years in the future.
Also weird that “the” Y2K bug was caused by Microsoft when lots of the offending (probably) Cobol code was written before Microsoft was business, I would think.
I do not blame Microsoft for any Y2K bugs caused by COBOL, unless it was their COBOL. I never claimed the only Microsoft caused Y2K bugs. But I’ll blame them for all the non-Apple PC bugs. It was a trivial fix that could have rolled out with MSDOS 4 and not be a universal headache in the PC world.
But there is another ‘adjustment’ needed. Originally the plan was for the year 15000 to not be a leap year. More recently the choice has been either 3000 or 4000 not being a leap year. My guess is it will be 4000. Will 8000 also be not a leap year? In any case, plenty of time to get ready.
Got a reference for further discussion of these possibly needed “adjustment” years? I can’t find anything.
If you look under the Accuracy heading in https://en.wikipedia.org/wiki/Gregorian_calendar you will find some discussion. Sir John Herschel originally proposed the years that are a multiple of 4000 not be leap years. Unfortunately, when people started launching satellites (and sending some passenger jet flights around the Earth) this changed the length of the day–very slightly. You can read more on that subject as “leap seconds.” Global warming also messes with the length of the day. As the oceans warm, the sea level rises and this slows down the rotation of the Earth.
Also, back when, I thought it would be nice to have a program that got the day of the week and number of days between a Julian date and a Gregorian date correct. Unfortunately that was way too messy. Some countries have more than a dozen dates when they changed from the Julian to the Gregorian calendar. France made it even messier with the French Revolutionary calendar and one province which changed back from the Gregorian to the Julian calendar for a short period.
Also just to make it a bit nastier. Astronomers decided to use Julian days but with the date changing at noon GMT–all around the world.
Thanks. So, from that link, it’s all due to complex orbital and rotational dynamics factors. Very interesting stuff!
Looks like the earnings presentation is pushed to February 1st.
https://ir.amd.com/news-events/press-releases/detail/1042/am…
Intel is also announcing much later than usual on 1/26
Alan
Yahoo finance is carrying a story from the Motley fool that AMD is a buy before earnings. The article can be seen on the front page here https://finance.yahoo.com/quote/AMD/ You may need to be a subscriber to see the full story.
Direct link to the article, bypassing Yahoo. No subscription needed
https://www.fool.com/investing/2022/01/28/tech-sell-off-down…
None of the info in the article is new for us, but could help inform other investors.
Results out, Q4 earnings $0.80 (GAAP), $0.92 (Non GAAP) beats estimates. After hours market SP up around $11.00.
Good results imv. Have not looked at where the income came from, yet.