Reply to thread

Message: [QUOTE="Alan J. Flavell, post: 4747961"] I don't think there's any real disagreement over that, unless the limitation under discussion was in the department of "inability of the code to protect itself against dangerous input from the client", in which case I'd rate it as not only a limitation but also a bug. However, it's a fact of programming life that the initial design and implementation often represents only a tiny fraction of the software's total lifetime support implications. So a program that can only produce a single date format might very well later be called upon to produce a different format, or to correctly report the time in someone else's timezone, or whatever. So an initial design which is capable of being easily extended to do these things may offer some real advantages over one that will need additional one-off code development to achieve the same result, in terms of later maintenance commitments. Case in point: a few days after the end of European daylight savings time this year, I had occasion to deal with a USAn videoconference booking system. It thought that the clock time in the UK was BST (it was not) and numerically the same as in Geneva(CH) (it was not) and an hour away from the time in Hamburg(DE) (it got that much right). When I reported the discrepancy, I was told "the software can be tweaked". I'm sure it can, but why would it need to? Computer systems in the various locations _know_ the correct time and timezone for any supported locale - their sysadmins do not need to "tweak" them. Evidently the company that implemented the videoconferencing server had re-invented a square wheel, no? [/QUOTE]

Verification