Last post Apr 01, 2014 12:05 PM by NinjaLord
Apr 28, 2004 08:47 PM|rehman|LINK
Apr 29, 2004 12:23 AM|thona|LINK
::WHY must I supply a date parameter for a sp as 'mm/dd/yy'. Because of the serers on the settings. BTW - noone says you need to provide this format, you can ALSO provide a time agnostic form, known as ISO form (well at least on sensible database systems
- you interesting enough forgot to tell us what datbase you use). RTFM and look up on international date and time formats. Something along this: yyyy-mm-dd should also be accepted. This is the ISO norm. ::How should end users enter the date. In THEIR SET LOCALE.
If I come to you with a browser saying I am german, with german locale, it is YOUR task to deliver dates to me in german formatting, and parse german formatting. Which is extremely easy given that you simply have to do nothing to do exactly this. Just parse
it. ::Can I store 'dd/mm/yy' and 'mm/dd/yy' format dates in the same table? You do not and you should not. See, any sensible program will store data not as string but as a date & time value. DateTime struct in .NET, datetime / smaldatetime field type in sql
server. And these do not store your formatting, they store the VALUE in it. What you see is then only the presentation. So, if you do not marvelously **** up by storing the date as a string (which was, btw., very common in anvient times in cobol) you will
store it in a presentation independant format ANYWAY. Which means that you simply do not care about this. And it means you can not store the two forms in the table, as NO form is stored, just some numbers that represent a point in time. Hoiw do you deal with
this? SImply by moving datetime formats (structures) back and forth. And using international form when writing / generating SQL Strings.
Apr 01, 2014 12:05 PM|NinjaLord|LINK
IRI CoSort and likely NextForm (data migration tool) has date masking for re-structuring the date elements into the target column format. See