If the client's clock is ahead of the server's clock, it is invalid to specify a date/time that is after the server's current clock (the HTTP spec even says so).
If the client's clock is behind the server clock's, at the very least you might end up with a 200
reply when you might be expecting a 304
reply instead, which is not an error but would waste bandwidth sending a really-unmodified resource.
Either way, you are better off using the server's date/time values. In fact, the HTTP spec does says so in section 14.25:
Note: When handling an If-Modified-Since header field, some servers will use an exact date comparison function, rather than a less-than function, for deciding whether to send a 304 (Not Modified) response. To get best results when sending an If- Modified-Since header field for cache validation, clients are advised to use the exact date string received in a previous Last- Modified header field whenever possible.
Note: If a client uses an arbitrary date in the If-Modified-Since header instead of a date taken from the Last-Modified header for the same request, the client should be aware of the fact that this date is interpreted in the server's understanding of time. The client should consider unsynchronized clocks and rounding problems due to the different encodings of time between the client and server. This includes the possibility of race conditions if the document has changed between the time it was first requested and the If-Modified-Since date of a subsequent request, and the possibility of clock-skew-related problems if the If-Modified- Since date is derived from the client's clock without correction to the server's clock. Corrections for different time bases between client and server are at best approximate due to network latency.