Try examining the certificate that you're receiving. It's not always about date/time, certificates are being validates by your browser based on the certificates store (trusted root certification authorities, etc.). If, for some reason, a certificate presented by a site fails verification, you'd get a warning. The most common scenarios:
1. Time/date, as you mentioned (certificates have a "valid until" and "not valid before" value.
2. CN does not match the one on the certificate - the browser validates a server certificate based on an FQDN (domain name) or an IP (also called "alternate name" on the certificate), depends on what's inside the certificate. For example, if you open
www.google.com" target='_blank'>https://<<
www.google.com's IP
>>, the certificate can only be verified against
www.google.com and not 1.2.3.4.
3. Everything is okay with the certificate, but you don't trust the one who published it. By "you", I actually mean your browser's vendor. They're the ones that decide which certification authorities are trusted, which means that certificates signed by them are trusted as well (as long as 1 and 2 are okay). In some cases, sites decide to become their own certificate authority (The Pirate Bay did that once). On some other cases (which is the main reason you shouldn't trust certificates out of nowhere), someone (or an organization) in your path to the site intercepts your connection and presents its certificate, meaning that, once trusting it, they'd be able to see the encrypted data. NEVER trust certificates in that case unless you're using your work network, in which case you should then understand that your IT department will know what it is you're doing over an SSL (HTTPS) connection.
Plain HTTP doesn't perform any PKI (in layman's terms, certificate) operations, so if your only goal is to reach the data without errors and no security, just use HTTP.
HTH.