Сравнить нельзя обновить

Ну, допустим, хочется сделать скрипт проверки и обновления какого либо файла из интернет. Хороший такой скрипт, чтобы лишней нагрузки на сервер не создавал, и лишний трафик не гонял. То есть, необходимо проверять обновление какого-либо ресурса по URL, и, при необходимости, загружать новую версию, или как-то по иначе отреагировать, письмо, например, послать. Тут на помощь приходят заголовки HTTP Last-Modified (в ответе сервера) и If-Modified-Since или If-Unmodified-Since(в запросе). При ближайшем рассмотрении оказывается, что значения в этих полях не имеет смысла из строкового приводить к типу datetime в принципе, независимо от языка программирования. Во-первых, в соответствии с RFC2616 HTTP-date может кодироваться несколькими способами, для учёта разных вариантов может понадобиться нетрифиальная логика или специализированная библиотека. Во-вторых, тот-же RFC2616 в разделе про If-Modified-Since рассказывает про отсутствие синхронизации времени на клиенте и сервере, что в некоторых алгоритмах может приводить к race condition. Вообщем, правильный алгоритм, должен значение из Last-Modified посылать в If-Modified-Since именно в том виде, в каком получил, не устраивая локальные проверки соответствия времени модификации локального файла времени модификации файла на сервере. Собственно, спецификация так прямо и говорит:

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