I'm assuming that you've used the "Live HTTP Headers" add-on for Firefox/Mozilla or an on-line server response header checking tool to check your cache-control and expiry headers, and that they are correct, marking these objects as cacheable.
But it is up to the client cache (or corporate or ISP cache) to decide when to check an object for freshness. We can only make our servers give them a 'hint' about how long an object is to be considered 'fresh.'
In some ways, you 2038 expiry date may be counter-productive, in that the client cache-control logic 'may not believe you' and think that the 2038 date is an error, and that your server is sending the 'default' last-possible date in the *nix calendar. Try setting the expiry date to a more reasonable time, such as 90 days -- This is a long time in the caching world, and the effect on your server bandwidth is likely to be negligible.
To be clear, changing your cache expiry time from 30 years to 30 or 90 days won't raise you bandwidth much, whereas changing it from three days to one hour would. The expiry-time versus bandwidth graph is a curve, with a very sharp rising slope from minutes to hours, but a very long, slowly-rising slope from days to months. The part of the curve from months to years is almost flat -- essentially showing no benefit to extremely-long expiry times.
Consider that most cache entries will be flushed to make room for newer cacheable objects, caches will be cleared, and browsers, operating systems, and computers replaced long before a 2038 expiry time is reached...