|
what cleared a lot of confusion for me was when someone explained to me that a date field has no native format that concerns us. It is stored in the data base in some mysterious and unknown fashion. One person told me it is in fact a 4-character field that contains the date.
I think of it a little differently.The original problem was that we stored dates in numeric or character fields. When you do that, the system doesn't know that it's a date. It thinks it's a number. Or character string. In either case, it doesn't know that it's a date at all. It doesn't know that part of it is a year, part of it is a month, part of it is a day.
With the date data type, this is no longer true. Now the system DOES know that it's a date. It DOES know which parts of it are the year, month and day.
So, even if the dates aren't in the same format, they can be compared against each other. Why? Because in both cases, the system knows which part is the year, which part is the month, and which is the day. If it knows that, it can compare them against each other without problems.
Similarly, when you use EVAL or MOVE with date, it doesn't blindly copy one to the other, byte by byte. Why would it? It knows which part is the year, month and day, and it assigns them accordingly. So it doesn't matter if one is *ISO, and one is *USA. Why would it? It knows in each case where the subfields are, and copies them appropriately.
The only reason it needs a date format at all is so that it knows how the user should view it.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
