I'm trying to pull some data from a 3rd party SQL Database into my tables. The dates are all INT and make no sense to me FWIW the APP is based on Cobol. I was expecting "Days since Epoch" or something like that ... but it doesn't seem to map

I reckon that the Cobol datatype is an UNsigned INT and, as such, the dates run from 0 to 32,767 and then from -32,768 to -1 ... but even that isn't mapping for me.

I have a handful of INT numbers and their actual date counterparts - in case anyone can figure out the mapping please

Just guessing here, but could it be that the dateno represents number of days from at given start date minus "holydays" from another table?
Regarding the "integer overflow", you could turn negative numbers to positive like this: (t1_dateno&0x8000)+(t1_dateno&0x7fff)

Hehehe ... and there I was worrying about why they had "wasted" a day for each month!

I still find it inconceivable they would have come up with such a concept ... can't do "Days between these dates" or anything like that. "Days since Epoch" would have been far more useful, but I also cannot understand why, when they moved from ISAM to SQL, they didn't convert the dates to SQL DataType DATE / DATETIME - no possibility of doing any useful Date reports in SQL - other than ORDER BY MyDateColumn - and then even that doesn't work when the dates bridge the positive/negative point

Many years ago, I worked at a company where out developer/production environment was cobol on a HP3000. We used ISAM and as I recall, there was a kind of "sql layer" on top of the ISAM, so we were able to query using sql. But as "the old cobol guys" were used do the "start/fetch next" thingy, I was not allowed to incorporate sql queries in the programs. May it is the same you encountered, where their programs was not changed to do sql queries ?!?
Anyway - if they were concerned to optimize for size (as it was common "back in the day"), they still "wasted" a day, as the value range zero to 31 counts 32 days (I know I'm splitting hairs now).

there was a kind of "sql layer" on top of the ISAM, so we were able to query using sql. But as "the old cobol guys" were used do the "start/fetch next" thingy, I was not allowed to incorporate sql queries in the programs.

Yup, that's exactly it. Its pretty smart actually, the COBOL program talks to the ISAM thingie, and that is capable of saying "Right, that stuff is now in SQL" and getting it from whichever store is now "current", so the data can be ported over time. But here we are in 2017 and still 80% of their data is in ISAM ...

But its not a SQL database as we would know it. No clustered indexes, no PKeys, no FKeys, no NULLs ... along with "No DATE datatype ... so it would be pretty hard to use SQL to query it effectively.

I've created a VIEW but the performance will be dreadful for general SQL queries - 50% of the 100+ columns are dates with your magic date formula

Don't suppose anyone will ever stumble over a need to use this! but just in case they do:

The BITWISE Maths is very efficient ... but I have a slight worry that the data MIGHT have a modulo-32 INT value that maps to 31-Feb Using the "Add Days and Months" BITWISE maths would just add "a few extra days" to the date, and I would wind up with 03-Mar (or 02-Mar in a leap year) rather than an error. I would prefer the error ...

I've done a check on a couple of the date columns and did not find any 31-XXX in 30-day months, or 29-31 Feb, so perhaps all is well, but I might change the DATEADD(Day, ... DATEADD(Month, ... to use DATEFROMPARTS() instead.