This made me wonder: once it had deleted item "0", did it feel unsatisfied and start to rip into my music library like a hungry goat, or what?
This made me wonder: once it had deleted item "0", did it feel unsatisfied and start to rip into my music library like a hungry goat, or what?
@tster said:
I noticed that the destination on that package is Shrewsbury... May I ask where you live? I live in Worcester.
Shrewsbury isn't the final destination - it's actually an interim stop on the way to Waltham, where I work.
@MasterPlanSoftware said:
Has anyone else noticed the OP isn't really even referring to the uniqueness of the numbers? I think his issue is the delivered on date being 2005 when it was shipped in 2007. Whether the numbers are unique or not, the dates should be correct.
Maybe I am missing some history that would help me understand why everyone is ignoring that....
I was referring to the lack of uniqueness. If they used unique numbers, I wouldn't see two order histories listed in the tracking page, and the summary page wouldn't say "Delivered in 2005" either.
Uniqueness for them is one thing, but uniqueness for the user should be their priority. As soon as I got emailed my tracking number, it looked like my package had been already delivered - and to the wrong state, at that!
Total WTF moment indeed.
At the very least, they could do some simple manipulation on the tracking page to avoid this - if there are any "Delivered" dates, the tracking page should list those entries newer than that delivery date. Adding a button to allow you to "View older packages with this number" would get you the historical data.
Seriously, when was the last time you looked up the status on a 2-year old already-delivered package?
Ya know, UPS must ship a LOT of packages -- they're already reusing numbers from only 2 years ago!
Those 18-digit tracking numbers just can't keep up with the demand...
Notice anything about this screencap which I pulled off my TiVo last week?
Will that code even compile on decent C++ compilers? They would prevent (or at least give a warning) when a const char* (returned from c_str()) is trying to be coerced to a char* without a const_cast<>.
See it live for another hour or so until rush hour dies down:
http://www.boston.com/traffic/3.shtml
Otherwise, see it here saved on ImageShack: