I can feel with you. Testing against timestamps and such can be a pain.

A good friend of mine once wrote an NNTP archiver (searchable HTML). Took him a while to figure out why a specific users messages would always fail to parse. After a week or so of tinkering, this is what he found:

The message date header was (as far as i can remember) in the form of "Mon 25th Dec. 2011 18:00:00". Except this specific NNTP client did the day of the week calculation wrong (25th Dec 2011 would be a sunday, not a monday). Since this where all some years old messages, finding the problem was not as obvious as glancing at the calendar.

Turns out that the date parsing module my friend used did the parsing and validation correctly. And it therefore rejected the date given due to having the wrong day of the week. Solution was to remove the day name via regex - and then it all worked out. That's how i learned to appreciate the mantra from RFC1122: "Be liberal in what you accept, and conservative in what you send"

As for calendar week (week of the year) which you seem to use: Yeah, like all Date and Time calculation, this has been historically quite confusing. And given all this leap year stuff, it's hell to get right all the time (excuse the pun). You're quite fortunate that you don't need "seconds since ..." resolution, that would be impossible to get right by calculation: leap second "For example, currently it is not possible to correctly compute the elapsed interval between two instants of UTC without consulting manually updated and maintained tables of when leap seconds have occurred. Moreover, it is not possible even in theory to compute such time intervals for instants more than about six months in the future."

So, in effect, i can feel your pain. And i thank you for this meditation.

BREW /very/strong/coffee HTTP/1.1
Host: goodmorning.example.com

418 I'm a teapot