Data | Databases often see people asking questions about time formats, such as incorrect time formats from a database that fit your heart. Because of the difference between the operating system and the database version, this problem does exist. Some people like to be in the data from the database after the definition of type, I think this does not grasp the source, so I want to say what I think.
In fact, it's also very simple, without century (yy) with century (yyyy) in SQL Help
Standard
input/output**-0 or MB (*) Defaultmon DD yyyy hh:miam (or PM) 1101usamm/dd/yy2102ansiyy.mm.dd3103british/frenchdd/mm/ Yy4104germandd.mm.yy5105italiandd-mm-yy6106-dd Mon yy7107-mon dd, yy8108-hh:mm:ss-9 or 109 (*) Default + Millisecondsmon DD yyyy Hh:mi:ss:mmmAM (or PM) 10110usamm-dd-yy11111japanyy/mm/dd12112isoyymmdd-13 or 113 (*) Europe default + millisecond SDD Mon yyyy hh:mm:ss:mmm (24h) 14114-hh:mi:ss:mmm (24h) -20 or (*) ODBC canonicalyyyy-mm-dd hh:mi:ss (24h) -21 or 121 (*) O DBC canonical (with milliseconds) Yyyy-mm-dd hh:mi:ss.mmm (24h) -126 (* * *) ISO8601YYYY-MM-DD Thh:mm:ss:mmm (no spaces)-130 *kuwaitidd Mon yyyy hh:mi:ss:mmmam-131*kuwaitidd/mm/yy Hh:mi:ss:mmmAM
So if you want to implement the time format of English in the Chinese system, you can use it in the stored procedure.
Select Date1=convert (char (), date1,101) is the format that converts date1 to mm/dd/yy.
It's still very convenient. Of course, the data after the removal, or individual data can also be passed. String ("Yyyy-mm-dd");