Forum Home
Press F1
Thread ID: 15844	2002-02-18 21:33:00	dd/mm mm/dd aaargh	Guest (0)	Press F1

Post ID	Timestamp	Content	User
36211	2002-02-18 21:33:00	This problem has plagued me while programming (in visual basic usually) for years and really I just want to know if anyone else experiences the problem of 02/03/2002 -- the 2nd of March, 2002 -- being interpreted American-style as 03/02/2002 -- the 3rd of February, 2002. The problem drives me wild and I continue to come up with hack solutions. Any answers? Tata	Guest (0)
36212	2002-02-19 04:02:00	Join the (very large) club. Been there, done that. What got me was the systems where the date had to be entered in two or more places, in different formats, US, restoftheworld, '-', '/', '.' separators, leading zeroes optional/forbidden/compulsory ... 19 Feb 2002 is OK (at least it is unambiguous), but the only sensible one is the ISO standard: yyyymmdd. That works, it's logical, unambiguous, and can have arithmetic performed on it to find date differences. The optional hhmmss can be used as well.	Guest (0)
36213	2002-02-19 11:25:00	I know what you mean. Really though, there are only two 'domains' to be considered: On the computer and off it. In other words, the date is either being controlled/handled/displayed by a computer system, or it's on paper. If it's on the computer there really is no problem: there will be a parameter somewhere that decides what the display format and the storage format is. Anyone using that computer will know what they are expecting to find. Switching between formats (to do date calcs) should be easy. On paper, the only solution I can think of is to stick to writing in the format dd-mmm-yy (e.g. 19-Feb-02). This is only one character more than dd/mm/yy and once you get in the habit, you will never again be misunderstood in your written communications with other countries.	Guest (0)
36214	2002-02-20 03:14:00	Sorry John, that's not quite true. Computer generated information often has to be transported to other computers. I have had a lot of experience of doing this. I would never trust any computer system to NOT get dates wrong. Murphy's Law has no exceptions. I would not trust any package's date formats. If the format be set in different ways it will be set wrongly. If dates are stored in binary form (for space saving) and there are selectable formats, the dates CAN NOT BE TRUSTED. It is that simple. The yyyymmdd[hhmm[ss]] format stored as text is totally unambiguous and can be sorted or compared without type conversion. Numeric operations need a simple conversion. You can save 1 character by using daynumber (wrongly called 'Julian day') and year: yyyyjjj, but it's less user-friendly ... On paper, it's a matter of taste: it's quite elegant to use (lower case )roman numerals fot the month: '20 ii 2002'. To be super elegant, you could use uppercase Roman numerals for the year (MMII this year).	Guest (0)
1