Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Date Picker Format
- Thread starter stahorse1
- Start date
What is a format expression with only 3 y's supposed to give you?
I'm curious why you would need this format.
Format(Date,"yyyymmdd") gives 20131213
Format(Date,"yyymmdd") gives 133471213 which I suggest is invalid
Format(Date,"yymmdd") gives 131213
An IsDate on all results reports false unless you use yyy/mm/dd
I'm curious why you would need this format.
Format(Date,"yyyymmdd") gives 20131213
Format(Date,"yyymmdd") gives 133471213 which I suggest is invalid
Format(Date,"yymmdd") gives 131213
An IsDate on all results reports false unless you use yyy/mm/dd
One huge advantage of the DateTimePicker control is that it is regional aware. This means that it uses settings from windows to control how it displays. Specifically, if you are set to US English, it will display (to the user) dates in day/month/year format. Please understand that this is a display only thing. Under the hood, the DateTimePicker control stores the value as a Date. When you step through the code and look at the .value property, the VB6 IDE is showing that value to you formatted using your regional settings (which I suspect is day/month/year).
The significance of this is... when you install your app on a computer that has regional settings different than yours, it will display the date to the user in their preferred format.
I am from the US. Most of my customers are also in the US. I do have a couple customers in Canada. I recall many years ago running in to a problem with my Canadian customers related to this exact situation. I switched to the DateTimePicker control so that the user would see a date formatted the way they are accustomed to seeing it (some people in Canada prefer month/day/year). I then handle the data in code as a Date value. My app uses a SQL Server database. When saving the data, I use parameter objects which can handle date variables so I never have problems with "date ambiguity" (is the m/d/y for d/m/y ???).
Basically, what I am trying to say is... the best way to handle dates in your application is to keep the data in Date variables as much as possible. It's only when you convert a date to a string and vice versa that you will run in to problems. By using the DateTimePicker control, you are letting the control do all the work for you.
If you can't use a parameter object like I do, then just format the .value property like strongm suggested in your other thread.
msgbox(DateTimePicker.Value, "yyyymmdd")
Does this make sense?
-George
Microsoft SQL Server MVP
My Blogs
SQLCop
twitter
"The great things about standards is that there are so many to choose from." - Fortune Cookie Wisdom
The significance of this is... when you install your app on a computer that has regional settings different than yours, it will display the date to the user in their preferred format.
I am from the US. Most of my customers are also in the US. I do have a couple customers in Canada. I recall many years ago running in to a problem with my Canadian customers related to this exact situation. I switched to the DateTimePicker control so that the user would see a date formatted the way they are accustomed to seeing it (some people in Canada prefer month/day/year). I then handle the data in code as a Date value. My app uses a SQL Server database. When saving the data, I use parameter objects which can handle date variables so I never have problems with "date ambiguity" (is the m/d/y for d/m/y ???).
Basically, what I am trying to say is... the best way to handle dates in your application is to keep the data in Date variables as much as possible. It's only when you convert a date to a string and vice versa that you will run in to problems. By using the DateTimePicker control, you are letting the control do all the work for you.
If you can't use a parameter object like I do, then just format the .value property like strongm suggested in your other thread.
msgbox(DateTimePicker.Value, "yyyymmdd")
Does this make sense?
-George
Microsoft SQL Server MVP
My Blogs
SQLCop
"The great things about standards is that there are so many to choose from." - Fortune Cookie Wisdom
>Format(Date,"yyymmdd") gives 133471213 which I suggest is invalid
Um - not invalid, just odd.
Unlike .NET, for which "yyy" is a legitimate custom format, VB only supports "y", "yy" and "yyyy". And knowing that, perhaps you can see what is going on here.
Um - not invalid, just odd.
Unlike .NET, for which "yyy" is a legitimate custom format, VB only supports "y", "yy" and "yyyy". And knowing that, perhaps you can see what is going on here.
I agree, for some reason in design view it will not accept most custom formats. It appears to save it, but when you run it it does not.
Example. this works
yyyy MM dd
but
yyyyMMdd
does not
However if you set it in code you can do most formats. It appears to be an issue with the ActiveX control
Dim dtp As MSComCtl2.DTPicker
Set dtp = Me.dtpYear.Object
dtp.Format = dtpCustom
dtp.CustomFormat = "yyyyMMdd
Example. this works
yyyy MM dd
but
yyyyMMdd
does not
However if you set it in code you can do most formats. It appears to be an issue with the ActiveX control
Dim dtp As MSComCtl2.DTPicker
Set dtp = Me.dtpYear.Object
dtp.Format = dtpCustom
dtp.CustomFormat = "yyyyMMdd
- Status
Similar threads
- Locked
- Question
