7 ms·

Ha. I had an intern who wrote code that blew up if the timestamp of our DB server was ever >= 1 second after the timestamp of our app server. It couldn't fail

Ha. I had an intern who wrote code that blew up if the timestamp of our DB server was ever >= 1 second after the timestamp of our app server. It couldn't fail at his desk, because he ran both servers locally while developing. And it wouldn't fail in production in the morning, since we had a cron job that synced the clocks at midnight. It took until after 5pm for the clocks to drift enough, meaning I was on call and the intern was not. But the bug didn't crop up until his code had been in production for a couple of weeks, so it was a real pain in the neck to track down.

barbs 5y ago
I'm surprised that got through code review
- knodi123 5y ago
  This was the early 2000s, at a very small startup funded privately by a non-technical guy, and most of the technical staff was under 25. It's a big world, and best practices are not universal.
bentcorner 5y ago
Personally I really don't like code that deals with time - it's too easy to place a "get time stamp" call anywhere in code. If it's down in the bowels of some piece of functionality trying to test it becomes a headache.
- sandinmyjoints 5y ago
  This is one of those pieces of software engineering wisdom that only comes from experience. Try explaining to a newish dev why they shouldn't `const now = Date.now()` or whatever anywhere they want, but rather do it in one place for the lifecycle and pass it around, and they will look at you funny and think it's a waste of time. Classic case of simple vs easy. Time has the potential to complect everything it touches.
  - Spoom 5y ago
    Oh yes. Any time I see code that tries to do some kind of scheduling, the first thing I ask is if they have considered using a library someone else has written. Way too many things can subtly go wrong, but new folks tend to think it should be easy, because how hard can it be to work with dates?
    - tentacleuno 5y ago
      > because how hard can it be to work with dates? Oh man, tell me about it. Timezones are the worst. No wonder so many people just give up and use Moment.js.
      - dheera 5y ago
        Use UTC UNIX timestamps (i.e. Date.now()) for ALL time-related processing and only convert to hours/minutes when taking input/output from the user.
        aidos 5y ago
        Uh oh, we’re going there again. If you’re doing anything in the future, that’s not always the correct thing to do. (Instants vs wall time etc)
        mypalmike 5y ago
        That's a good starting point, and certainly good advice for marking current time and past times. But keep in mind that future event absolute UTC can change due to politics, e.g. a change in daylight savings rules, which is less rare than you might imagine (https://en.m.wikipedia.org/wiki/Daylight_saving_time_by_country#Past_observance https://en.m.wikipedia.org/wiki/Daylight_saving_time_by_coun...). That concert scheduled a year from now at 8pm in UTC+5 might actually end up occurring at 8pm in UTC+6.
        notreallyserio 5y ago
        > certainly good advice for marking current time and past times But not too far past!
- deleted 5y ago
  [deleted]
- jimmaswell 5y ago
  Not too bad testing these things with mocking libraries.
- artdigital 5y ago
  Move the date up a layer and pass it into the code that deals with it, makes it easy to write tests for it
inquist 5y ago
> an intern who wrote code .... his code had been in production You get what you pay for, eh?
- darkwater 5y ago
  A cronjob to sync the time instead of a proper NTP client doesn't sound that good either. I know that each place has its own weird things because historical reasons but NTP is quite ancient.
  - knodi123 5y ago
    Our sysadmin was being paranoid about how many memory-resident programs we ran. he figured time syncing wasn't important enough to justify a daemon, so he just ran the ntpdate command on a daily schedule. It wasn't that bad - after all, how far can clocks drift in a single day!? ;-)
    - shadowoflight 5y ago
      Guess it's time to change the `0` in that cronjob to a `*/12`.
    - krick 5y ago
      Admin like that sound a lot worse than the intern. Unless maybe if it's an intern-admin...
    - xorcist 5y ago
      If you are to be paranoid about time, better be paranoid about stepping time. Time discontinuities can trigger bugs in the best of software.
    - tristor 5y ago
      > he figured time syncing wasn't important enough to justify a daemon Time synchronization is very arguable THE most important thing on a server (for numerous security related reasons). How many moons ago was this incident? It's perhaps forgivable ignorance in the 90s... not so much today.
amelius 5y ago
To be honest, I wrote code that blew up after the time server updated the time from the network, a few seconds after booting.

barbs 5y ago

I'm surprised that got through code review

knodi123 5y ago
This was the early 2000s, at a very small startup funded privately by a non-technical guy, and most of the technical staff was under 25. It's a big world, and best practices are not universal.

bentcorner 5y ago

Personally I really don't like code that deals with time - it's too easy to place a "get time stamp" call anywhere in code. If it's down in the bowels of some piece of functionality trying to test it becomes a headache.

sandinmyjoints 5y ago
This is one of those pieces of software engineering wisdom that only comes from experience. Try explaining to a newish dev why they shouldn't `const now = Date.now()` or whatever anywhere they want, but rather do it in one place for the lifecycle and pass it around, and they will look at you funny and think it's a waste of time. Classic case of simple vs easy. Time has the potential to complect everything it touches.
- Spoom 5y ago
  Oh yes. Any time I see code that tries to do some kind of scheduling, the first thing I ask is if they have considered using a library someone else has written. Way too many things can subtly go wrong, but new folks tend to think it should be easy, because how hard can it be to work with dates?
  - tentacleuno 5y ago
    > because how hard can it be to work with dates? Oh man, tell me about it. Timezones are the worst. No wonder so many people just give up and use Moment.js.
    - dheera 5y ago
      Use UTC UNIX timestamps (i.e. Date.now()) for ALL time-related processing and only convert to hours/minutes when taking input/output from the user.
      - aidos 5y ago
        Uh oh, we’re going there again. If you’re doing anything in the future, that’s not always the correct thing to do. (Instants vs wall time etc)
      - mypalmike 5y ago
        That's a good starting point, and certainly good advice for marking current time and past times. But keep in mind that future event absolute UTC can change due to politics, e.g. a change in daylight savings rules, which is less rare than you might imagine (https://en.m.wikipedia.org/wiki/Daylight_saving_time_by_country#Past_observance https://en.m.wikipedia.org/wiki/Daylight_saving_time_by_coun...). That concert scheduled a year from now at 8pm in UTC+5 might actually end up occurring at 8pm in UTC+6.
        notreallyserio 5y ago
        > certainly good advice for marking current time and past times But not too far past!
deleted 5y ago
[deleted]
jimmaswell 5y ago
Not too bad testing these things with mocking libraries.
artdigital 5y ago
Move the date up a layer and pass it into the code that deals with it, makes it easy to write tests for it

inquist 5y ago

> an intern who wrote code .... his code had been in production You get what you pay for, eh?

darkwater 5y ago
A cronjob to sync the time instead of a proper NTP client doesn't sound that good either. I know that each place has its own weird things because historical reasons but NTP is quite ancient.
- knodi123 5y ago
  Our sysadmin was being paranoid about how many memory-resident programs we ran. he figured time syncing wasn't important enough to justify a daemon, so he just ran the ntpdate command on a daily schedule. It wasn't that bad - after all, how far can clocks drift in a single day!? ;-)
  - shadowoflight 5y ago
    Guess it's time to change the `0` in that cronjob to a `*/12`.
  - krick 5y ago
    Admin like that sound a lot worse than the intern. Unless maybe if it's an intern-admin...
  - xorcist 5y ago
    If you are to be paranoid about time, better be paranoid about stepping time. Time discontinuities can trigger bugs in the best of software.
  - tristor 5y ago
    > he figured time syncing wasn't important enough to justify a daemon Time synchronization is very arguable THE most important thing on a server (for numerous security related reasons). How many moons ago was this incident? It's perhaps forgivable ignorance in the 90s... not so much today.

amelius 5y ago

To be honest, I wrote code that blew up after the time server updated the time from the network, a few seconds after booting.