Originally Posted by medialint
it's specifically looking for files within the last ten days and only keeping 10 days worth of files on the destination.
@LyonHaert -- really, it depends on how the code's written 
if you deal with 4-digit years in application code and only truncate for looking up data filenames, then the problem should not manifest itself until you try to look up something more than 100 years old (and then only because the naming convention does not allow more than 100 years' data)... similarly, as long as your file creation is destructive, you'll just overwrite 100-year-old files as the time period wraps around, and keep your 100-year window viable, uh, 'forever'...
consider this: I want to find all log files in the last ten days; I'm going to first find the date for 10 days ago, then truncate the year value, create the string, and find all the files between that string and the same for the current date. this may have a problem between christmas 1999 and early january 2000, but you'd have to write code around that anyway (since the years are only 2-digit in the filenames). in this case, the same code would suffice between christmas 2099 and early jan 2100. the only way your code would break on the stroke after midnight, jan 1 2100, is if you had a hardcode that literally prepends the string '20' to a 2-digit date, or that specifically removes the string '20' from the date (or, as a variant, the first 2 digits of the current century instead of the string '20'). am I wrong? and if so, why?
not trying to bug anyone... just trying to see if/where my logic fails on this one. obviously, just about all code written today will be gone in 92 years, but it's an interesting question of how viable the code will remain even with its centennial limitations. it's something I thought pretty heavily about 9-or-so years ago and hadn't thought of recently, so yippee for something fun to think about...
--derelict |
