4 ms·
Comparing dates that aren't UTC is a pretty amateur mistake. Comparing timestamps alone is a mistake too. It doesn't really matter why it broke to be honest, s
by sjs 16y ago
Comparing dates that aren't UTC is a pretty amateur mistake. Comparing timestamps alone is a mistake too.
It doesn't really matter why it broke to be honest, something like that has to be perfect or it's useless. After it breaks for someone it's impossible to trust the system again, negating any benefits. Once bitten twice shy.
They should have done their homework on distributed systems and used something like a vector clock. MS has lots of resources and absolutely no excuse for fucking this up. Especially since small startups have made similar services that actually work.
- cma 16y agoRe vector clocks, Microsoft even employs Leslie Lamport
- kenjackson 16y agoHe does work at MS, although I don't think vector clocks help here necessarily. I think a strict vector clock implementation _may_ simply tell you that there is no strict ordering in this case, as you had two independent events with no synchronization ocurring between the two (if we take the worst case scenario where they both go online to the service at the same time). UTC timestamps would solve the issue, unless you lied about your UTC time (hence the time change question). I must say, unlike the first respondant to my post, while I agree it should never happen -- I think understanding why it did is interesting in of itself. But I'm just one of those people who likes understanding how people make mistakes in software.
- sjs 16y agoI don't know enough here to say anything definitively, but I think knowing there's a conflict is half the battle. UTC timestamps are great but clocks have to be perfectly in sync which is unlikely even w/ NTP. And as you mentioned doesn't withstand users changing their system time. Sometimes bubbling conflict resolution up to the user is a good idea. It's preferable to data loss.