I'm stuck on how to do this so would appreciate a hand

Why on Earth would you want to do this without a module? Life is too short. But hey, just for kicks I thought I'd knock something out quickly. But then it started to become a hassle. But here's what you could do.

Firstly, as a gross simplification, you can say that a year is 365.25 days. At least that gets us off the hook of having to calculate leap years. As an approximation it works out pretty nicely. So... (2004-1970) * 365.25 * 86400 gives you an epoch of 1072958400. Adding in the number of days, hours, minutes and seconds in terms of seconds is trivial.

But then you have to determine how many days have elapsed since the first of January for each month (0 for January, 31 for February, 59 for March, 89 for April...) and then it sounds like not quite as much fun.

At this point you could build a lookup table to determine the value for you. And then to be correct, you should add one to the months beyond February if we're in a leap year (we are!). But hang on, if we're using a lookup table for the current year the Right Thing would be to also generate a lookup table to get the exact number of days year by year taking into account the leap years.

But hang on, that time value you gave, is that local time or UTC time? Is summer time in effect? And what about those pesky leap seconds that get introduced from time to time to take into account the slowing of the Earth's rotation?

How accurate do you want the answer to be? If you want it to be accurate, use a module that takes care of all these fussy details for you. Someone else has already sweated out the details. Otherwise just use an approximate calculation and be done with it.

Using the quick and dirty formula:

((y-1970) * 365.25 + (365.25 * (mon-1)/12) + day-1) * 86400 + ((h*60 + min) * 60) + sec

I get an epoch of 1087263294 which works out to be 2004-06-15 01:34:54 UTC. The true value is 1087220094. Is this error rate acceptable?