The SAY2K10 bug

Posted Jan 8, 2010 18:31 UTC (Fri) by MattPerry (guest, #46341)
In reply to: The SAY2K10 bug by Bayes
Parent article: The SAY2K10 bug

'current date + 1 day' would be even better.

The SAY2K10 bug

Posted Jan 9, 2010 0:26 UTC (Sat) by sfeam (subscriber, #2841) [Link] (4 responses)

'current date + 1 day' would be even better.

Not if you have correspondents on the other side of the date line.

The SAY2K10 bug

Posted Jan 9, 2010 3:22 UTC (Sat) by MattPerry (guest, #46341) [Link] (3 responses)

> Not if you have correspondents on the other side of the date line.

How so? Those correspondents will be, at most, only one day ahead. No timezone is more than 24 hours ahead of any other timezone. Therefore 'current date + 1 day' is sufficient.

The SAY2K10 bug

Posted Jan 9, 2010 8:02 UTC (Sat) by mp (subscriber, #5615) [Link] (2 responses)

Actually there are 26 hours between some places.

The SAY2K10 bug

Posted Jan 9, 2010 18:11 UTC (Sat) by MattPerry (guest, #46341) [Link] (1 responses)

Thanks for the links. I didn't know about those. Then 'current date + 26 hours' is sufficient. No need for 'current date + 1 year' since that would leave plenty of room for spammers to still set dates into the future.

The SAY2K10 bug

Posted Jan 14, 2010 0:53 UTC (Thu) by Kissaki (guest, #61848) [Link]

Not to pile on, but you don't want to be overly specific because sometimes people just make mistakes. If someone accidentally gets the month wrong when setting up or configuring their computer, and don't turn on NTP, you could be affecting their ability to send you email and (depending on what the email contains) give you money.

Egregious errors (wrong decade) are one thing, but 26 hours is probably cutting it too close.

I assume the reason it isn't dynamic is to be able to do static string matching / regular expression compilation, rather than recalculate the string to match every time. You could get past that by making it re-compute the date string on restart, assuming you restart frequently enough.