4 ms·

Don't forget the ancient proverb handed down to us from the original neckbeards: "At some point in their career, every programmer must pass through the fires o

by elwell 13y ago

Don't forget the ancient proverb handed down to us from the original neckbeards: "At some point in their career, every programmer must pass through the fires of timezone hell."

munificent 13y ago
Every programmer must enter those fires, but it's not certain that all of them will survive to emerge from the other side.
derefr 13y ago
Timezone hell is, of course, followed up with the three-headed hound of locales, charmaps, and keyboard layouts. And if you pass by that, you drop into the river of cache coherency... (Esoteric software-engineering topics could make a wonderful video game, you know?)
- ramses0 13y ago
  Turkey Test: http://www.moserware.com/2008/02/does-your-code-pass-turkey-test.html http://www.moserware.com/2008/02/does-your-code-pass-turkey-...
ericd 13y ago
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 throughout the year due to differences in daylight savings policy. It took a bit longer than I expected.
- 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

by elwell 13y ago

Don't forget the ancient proverb handed down to us from the original neckbeards: "At some point in their career, every programmer must pass through the fires of timezone hell."

munificent 13y ago

Every programmer must enter those fires, but it's not certain that all of them will survive to emerge from the other side.

derefr 13y ago

Timezone hell is, of course, followed up with the three-headed hound of locales, charmaps, and keyboard layouts. And if you pass by that, you drop into the river of cache coherency... (Esoteric software-engineering topics could make a wonderful video game, you know?)

ramses0 13y ago
Turkey Test: http://www.moserware.com/2008/02/does-your-code-pass-turkey-test.html http://www.moserware.com/2008/02/does-your-code-pass-turkey-...

ericd 13y ago

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 throughout the year due to differences in daylight savings policy. It took a bit longer than I expected.

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