without fully understanding what a uint32_t...
One of the mistakes in the C/C++ language standards is that the int type does not specify its size in bits. It is up to the compiler writer to decide. The avr-gcc compiler that is bundled with the IDE (for 8-bit MCU boards like the UNO and Mega) has chosen 16 bits (2 bytes). So int variables on those boards can have values between -32768 and +32767. An unsigned int can represent values between 0 and +65535.
There is a type called short int that is equivalent to char on the 8-bit MCUs has 8 bits (one byte), so it can represent values between -128 and +127.
But on the 32-bit Arduino boards (e.g., anything with a SAM processor, like a Teensy), the compiler writers decided on 32 bits for the int type. Variables of that type can have values between -2147483648 and +2147483647.
So if you want to write something like... I don't know... a GPS parsing library that works on all the different MCUs, you may need to know the range of values that your variables can have. If you always need an integer variable to have a certain number of bits, the de facto way to do this is with these "standard integer types":
| int8_t |
8-bit signed integer |
| uint8_t |
8-bit unsigned integer |
| int16_t |
16-bit signed integer |
| uint16_t |
16-bit unsigned integer |
| int32_t |
32-bit signed integer |
| uint32_t |
32-bit unsigned integer |
the (correct) time I'm getting with gps.time.value() is 12351900 (12h:35m;19.00s), but the "CurrentTime" variable will give me 1120424420.
Can somebody offer some insight? 
The TinyGPS++ library returns a 32-bit value for the current time that is the sum of the various time pieces, multiplied by powers of ten to move them into different digits of the base-10 number. When printed, you see the pieces all mashed together. You can access the pieces individually and print them however you want.
This form is not very friendly for doing date/time calculations. Adding 50 seconds, for example, means that the seconds roll over and you have to increment the minutes. If that rolls over, you have to increment the hours... days, month, year. And don't forget the possible leap day in one particular month. (I'm lookin' at you, February!) The code for these gets quite messy.
There's a better way to do this. Instead, pick a time "origin" for everything, like midnight January 1, 1970. Then calculate how many seconds there are from this EPOCH for your current date/time. Adding 50 seconds is easy: currentTimeSeconds += 50.
Then its fairly easy convert that new seconds value back into a date from the EPOCH. Because the calculations step from the epoch forward, the resulty might end up in a different year, month, day, hour or minute.
That's what the standard UNIX time libraries do. On the Arduino, you can use TimeLib. They all have two data types: a seconds count since the epoch (a 32-bit unsigned integer) and a structure to contain all the date/time pieces.
NeoGPS includes its own optimized time class, and there are examples for offsetting the GPS time (UTC or GMT) to the local time, with or without Daylight Saving Time (see NMEAtimezone.ino).
I hope you take a look at NeoGPS. It's faster, smaller, more reliable and more accurate than all other GPS libraries, and the examples are properly structured. It is very common for the other libraries' examples to break when they are modified. NeoGPS also includes methods for calculating distance and bearing very accurately, and it can parse several other messages, including the new messages from the NEO-M8 series (e.g., GNRMC).
NeoGPS is available from the Arduino IDE Library Manager, under the menu Sketch -> Include Library -> Manage Libraries. Even if you don't use it, there is lots of information on the Installation and Troubleshooting pages. Be sure the read the section about choosing a serial port, especially if you are using SoftwareSerial.
Cheers,
/dev