3 ms·

I once wrote a scheduling SAAS app, thinking it would be a short, trivial project. It turns out that UTC offsets don't even stay consistent within time zones th

• ams6110 13y ago
  We've probably all been there at one time or another, thinking that "unix timestamps" are all that's needed to represent and perform date/time calculations. Along with the recommendation to never inventing your own cryptography, you should also never write your own date/time routines. Use well tested functions in your database or programming language libraries.
  • ericd 13y ago
    Yeah, I ended up just using Ruby's time functions, but there were still a number of issues despite that (and I don't think they were fully baked).
  • jasey 13y ago
    At my first job I inherited a project from a snr dev who decided to implement his own date logic instead of using the ones provided in .net Anyway come feb 29th 2008 I get a call about some users were having issues. After not to long I figured out it was caused because of the leap year and his logic did not account for leap years. So I called them back and told them it would fix its self by tomorrow. I never actually bothered to fix the bug because a) I thought it was unlikely that the pos system would still be used in 4 years and b) the code was so bad in all areas that trying to fix anything had a good chance of breaking something else. Lets just say that job was very character building