The server needs to parse the date sent by the browser to compare it against the date the file was last modified (which is retrieved from the operating system, probably as UNIX time).
Browser: "I want index.html"
Server: "index.html was last modified on 'Pungenday, the 9th day of Bureaucracy, 3177 at 14:53'. Here are its contents."
[Time passes]
Browser: "I want index.html. I have a cached copy that you said was last modified on 'Pungenday, the 9th day of Bureaucracy, 3177 at 14:53'. Is there a newer version?"
Server: "Nope, your Last-Modified is the same thing I would tell you if I sent it right now."
Note that because the server sets the contents of last-modified for the browser, it can simply check if it's identical to what it would currently send as the last-modified header for that request.
To get that information the web browser must ask the file system when the file was last modified and compare it. It is recommended to do a "submitted time is less than time now" on the file (which means the date must be parsed), by the RFC (2616 14.25); however, some people do use inequality operators as you suggest.
In this case, it would be the web server that is not following the RFC (sending arbitrary Last-Modified header), not the browser.
To do correct time-based If-Not-Modified comparisons you really need to guarantee that all changes moves your Last-Modified time forward, no matter what. My view is that this is surprisingly hard once you start looking at corner cases. Certainly it's not something that a web server that serves general file content can ever guarantee; there are too many ways to shuffle files around behind the web server's back.