I would say that any good web developer should know how caching works - not just in browsers, but also proxies, firewalls, and every other link between your language parser (which may also cache) and the user's browser. It's "domain knowledge".
i consider knowledge of server caching is important thing a web developer need to know. i hardly doubt the knowledge of how browser cache is need to web developer. that's where the person comes in place called fronted developer or UI developer
A web developer needs to understand the entire chain of technology, from his text editor or IDE all the way to the browser. You don't need to be able to build a server from scratch (although you probably should be able to), but you need to understand how the pieces fit together (WSGI, mod_php, PHP_FPM, CGI, for example) and that includes which pieces of that chain can cache, might cache, will cache, and how they cache.
The front-end developer needs to be more concerned with browser-related issues, but doesn't need to know anything about the server stack (typically). The back-end developer likewise doesn't need to concern him/herself with browser issues, but needs a solid grasp of everything behind the browser.
A web developer has feet in both worlds and needs to understand much more than the front-end and back-end developers.
As an analogy, a gynecologist might be a front-end developer. He has a basic understanding of the entire human body, but specialized in this one area and everything related to it. People like to hang around him, hoping something will rub off.
A neurosurgeon might be more of a back-end developer (not what you thought, eh?). He's concerned with the code running things and how it will react with everything else. He can be hard to talk to, but always interesting.
The dermatologist is your UX guy. Presentation is his game, and nothing else (but he still understands the pieces that interact with his domain). His home is always awesomely decorated, but not always functional or obvious (the three shells on the toilet).
A general surgeon is the web developer. Solid understanding of everything, great at finding and solving problems, but knows when to leave something to the specialists. He lives in the home you wish you had, and his pool table always has great action.
I got carried away with that, but the tl;dr is: the web developer needs to understand the entire chain of his/her domain. There is no piece too small that you don't need to know something about it - like how it works, or how to fix common problems with it. From editor to browser, you need to understand how it all fits together.
I always use the integer representation. I believe (no testing) that it is faster due to the lack of a conversion step, math is always in seconds, and as long as the number you store is based on UTC (or GMT), there are no timezone issues.
For @gregjor's answer (having the DB create the date for you), it seems that if you actually need to know the timestamp of a newly inserted or updated record, you will actually need to make 2 SQL calls, since the record itself is not returned by UPDATE or INSERT.
INSERT and UPDATE don't return any row values, so whatever date/time column type you use you will have to do a SELECT to get it, if you need. I haven't run into this problem in practice; usually what I need is the last auto-incremented key value of a newly-inserted row.
If you are getting the date/time value outside of the database -- from a web application, for example -- and using that to insert into the database you will run into inconsistencies eventually because clocks on different will not be synchronized or will be set to different timezones. In my experience it's more important that all date/time values in a database come from a single source (the database server itself) rather than which column type you use. It's easier to control the clock and timezone in one place than require all database clients to be set to UTC and have their clocks synchronized.
Setting all clocks to UTC is not enough to get around daylight savings time issues, either. You actually have to know the timezone to do accurate date arithmetic. You can find lots of articles about this -- it's a pretty well worked-through topic. Think for a minute why every operating system and RDBMs and programming language date/time library aren't just using integers and assuming UTC.
Date/time types are native types in all serious relational database engines, so there's no conversion going on that you need to worry about. All RDBMSs have mature date/time manipulation operators and functions. If you use large integers you are going to be doing more conversions, especially once you have to deal with timezones. Think it through.
If they say no, I'd suggest Milles Bornes - a French card game from the 50s I used to play and love until I lost the cards back around the turn of the century :(
I consider this to be a UX failure: visit page, adjust one slider, select something from a pop-up, re-adjust the same slider, and when I hit the Back button nothing happens. Click Back again, nothing happens. Long-click the Back button and see 20 or 25 entries for the site even though I never left the front page or obviously loaded new content.
If they dump the JS that obliterates my browser history that way, then I would agree that it is indeed slick.
