Dates and Regional settings

[David Cox]

I am using VB6 as a front end for a Access 97 database. I have been using
the following code in a class module to enter data in the database:

Private Type ScaleReceiptProps
ID As Long
RecNum As Long
ScType As GMScaleTypes
scDate As Date
Gross As Currency
Truck As Currency
LoadNum As String * 20
Description As String * 500
InvoiceDetailID As Long
CategoryID As Long
SaleValue As Currency
Grade As String * 50
RelatedReceipt As Long
End Type

Private mudtProps As ScaleReceiptProps

Public Property Let scDate(NewVal As String)
If Not mflgEditing Then Err.Raise 383
If Not IsDate(NewVal) Then
Err.Raise InputErr, "ScaleReceipt", ErrDate
End If
If DateValue(mudtProps.scDate) <> DateValue(NewVal) Then
mudtProps.scDate = DateValue(NewVal)
ValueChanged
End If
End Property

I Googled about dates in VB6, and I think this code may not be the best way
to do it. As long as the PC's regional settings are 'English US' it should
work fine. If the setting happens to get changed to something else at some
point in the life of the database I think there may be errors. Here is the
changed code:

Public Property Let scDate(NewVal As Date)
If Not mflgEditing Then Err.Raise 383
If format(mudtProps.scDate,"MM/DD/YYYY")<>format(NewVal,"MM/DD/YYYY")
then
mudtprops.scDate = format(NewVal,"MM/DD/YYYY")
ValueChanged
End If
End Property

The variable NewVal would receive a DateTimePicker value property. Is this
code safe for regional settings?

[ralph]

Post by David Cox
I am using VB6 as a front end for a Access 97 database. I have been using
Private Type ScaleReceiptProps
ID As Long
RecNum As Long
ScType As GMScaleTypes
scDate As Date
Gross As Currency
Truck As Currency
LoadNum As String * 20
Description As String * 500
InvoiceDetailID As Long
CategoryID As Long
SaleValue As Currency
Grade As String * 50
RelatedReceipt As Long
End Type
Private mudtProps As ScaleReceiptProps
Public Property Let scDate(NewVal As String)
If Not mflgEditing Then Err.Raise 383
If Not IsDate(NewVal) Then
Err.Raise InputErr, "ScaleReceipt", ErrDate
End If
If DateValue(mudtProps.scDate) <> DateValue(NewVal) Then
mudtProps.scDate = DateValue(NewVal)
ValueChanged
End If
End Property
I Googled about dates in VB6, and I think this code may not be the best way
to do it. As long as the PC's regional settings are 'English US' it should
work fine. If the setting happens to get changed to something else at some
point in the life of the database I think there may be errors. Here is the
Public Property Let scDate(NewVal As Date)
If Not mflgEditing Then Err.Raise 383
If format(mudtProps.scDate,"MM/DD/YYYY")<>format(NewVal,"MM/DD/YYYY")
then
mudtprops.scDate = format(NewVal,"MM/DD/YYYY")
ValueChanged
End If
End Property
The variable NewVal would receive a DateTimePicker value property. Is this
code safe for regional settings?

Well, here is my two cents worth. I'll let the experts chime in with
specifics.

Frankly, I shudder whenever I see hard coded formats used in internal
calculations. Presentation only!

I get a queasy stomach any time I see someone attempting to apply
equality to 'date' or 'date strings' coming from two separate sources.
Or worse mixing them - Date to Date String.

I'll skip the chill that comes down my spine when I see 'Dates'
compared or piddled with without regard to the fact that most Date
data types are actually DATE-TIMEs. ie, there is a fractional part
hanging around there somewhere. You hope it is zero. <g>

All of that is only trouble brewing as Gary Larson used to say.

Keep 'Dates' in their native format which is a decimal. Store Dates as
Dates. Always capture dates as a 'DATE' data type. Always perform
calculations using the DATE data type. Appreciating that all 'Dates'
are floats and you can easily see why comparing for equality is
off-the-table. <g>

My advice: forget that Dates have any kind of string representation
(except for Presentation) and go back to re-write, before I become
seriously ill. <bg>

-ralph

[David Cox]

As Long

Post by ralph

Sale

Well, here is my two cents worth. I'll let the experts chime in with
specifics.
Frankly, I shudder whenever I see hard coded formats used in internal
calculations. Presentation only!
I get a queasy stomach any time I see someone attempting to apply
equality to 'date' or 'date strings' coming from two separate sources.
Or worse mixing them - Date to Date String.
I'll skip the chill that comes down my spine when I see 'Dates'
compared or piddled with without regard to the fact that most Date
data types are actually DATE-TIMEs. ie, there is a fractional part
hanging around there somewhere. You hope it is zero. <g>
All of that is only trouble brewing as Gary Larson used to say.
Keep 'Dates' in their native format which is a decimal. Store Dates as
Dates. Always capture dates as a 'DATE' data type. Always perform
calculations using the DATE data type. Appreciating that all 'Dates'
are floats and you can easily see why comparing for equality is
off-the-table. <g>
My advice: forget that Dates have any kind of string representation
(except for Presentation) and go back to re-write, before I become
seriously ill. <bg>
-ralph

Well, I'm open to all ideas. From what you say, is this the way it should be
coded:

Public Property Let scDate(NewVal As Date)
If Not mflgEditing Then Err.Raise 383
If Int(mudtProps.scDate)<>Int(NewVal) then
mudtprops.scDate = Int(NewVal)
ValueChanged
End If
End Property

Would the Int() function remove the times? Would the Date field (defined as
the Date data type) in the Access table store the date correctly no matter
what the regional settings are?

Sorry if my coding is making you ill! <g>

[ralph]

Post by David Cox
As Long

Post by ralph

Sale

Well, here is my two cents worth. I'll let the experts chime in with
specifics.
Frankly, I shudder whenever I see hard coded formats used in internal
calculations. Presentation only!
I get a queasy stomach any time I see someone attempting to apply
equality to 'date' or 'date strings' coming from two separate sources.
Or worse mixing them - Date to Date String.
I'll skip the chill that comes down my spine when I see 'Dates'
compared or piddled with without regard to the fact that most Date
data types are actually DATE-TIMEs. ie, there is a fractional part
hanging around there somewhere. You hope it is zero. <g>
All of that is only trouble brewing as Gary Larson used to say.
Keep 'Dates' in their native format which is a decimal. Store Dates as
Dates. Always capture dates as a 'DATE' data type. Always perform
calculations using the DATE data type. Appreciating that all 'Dates'
are floats and you can easily see why comparing for equality is
off-the-table. <g>
My advice: forget that Dates have any kind of string representation
(except for Presentation) and go back to re-write, before I become
seriously ill. <bg>
-ralph

Well, I'm open to all ideas. From what you say, is this the way it should be
Public Property Let scDate(NewVal As Date)
If Not mflgEditing Then Err.Raise 383
If Int(mudtProps.scDate)<>Int(NewVal) then
mudtprops.scDate = Int(NewVal)
ValueChanged
End If
End Property
Would the Int() function remove the times? Would the Date field (defined as
the Date data type) in the Access table store the date correctly no matter
what the regional settings are?
Sorry if my coding is making you ill! <g>

LOL, I'll get over it.

Yes Int() will work. Except can be non-intuitive for negative numbers,
but doubt that will be an issue unless you are an archeologist. <g>

Beware of the seemingly similar CInt(), it rounds I think.

And yes a Date type is stored as a decimal in MS Access, and MS Access
and VB share the same data types.

[The only problem you might run into is different internal formats if
you migrate from Jet. While all stores generally use a decimal type
for their internal storage, they can use a different starting date,
but that is a tad exotic, and in practice generally works itself out
due to the way SQL works.
However, any programmer that has worked with internationalization and
non-standard stores has a few horror stories to tell. <g>]

The other issue is 'concurrency'. For example, do you care if it is
actually tomorrow in Japan for a user in North America today?

-ralph

[Dr J R Stockton]

Post by David Cox
The variable NewVal would receive a DateTimePicker value property. Is this
code safe for regional settings?

Never use "regional settings"!. Either follow an applicable formal
International Standard, or limit yourself to your local custom, or
employ a term such as "user settings".

In the Great World Outside, and even in some cases within the USA,
location does not inevitably govern preference.

[David Cox]

Post by Dr J R Stockton

Post by David Cox
The variable NewVal would receive a DateTimePicker value property. Is this
code safe for regional settings?

Never use "regional settings"!. Either follow an applicable formal
International Standard, or limit yourself to your local custom, or
employ a term such as "user settings".
In the Great World Outside, and even in some cases within the USA,
location does not inevitably govern preference.
--
(c) John Stockton, nr London, UK. E-mail, see Home Page. Turnpike v6.05.
Website <http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc. : <http://www.merlyn.demon.co.uk/programs/> - see in 00index.htm
Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.

In that sentence I wanted to avoid regional settings. I wanted the code to
work despite any changes to regional settings. I wasn't trying to deal with
presentation in that code. I wanted to make sure that the date was saved
correctly in the database even if regional settings changed.

I have also changed the code to check for no date, I don't want to allow no
date by checking Int(NewVal)=0:

Public Property Let scDate(NewVal As Date)
If Not mflgEditing Then Err.Raise 383
If Int(NewVal)=0 Then Err.Raise InputErr, "ScaleReceipt", ErrDate
If Int(mudtProps.scDate)<>Int(NewVal) then
mudtprops.scDate = Int(NewVal)
ValueChanged
End If
End Property

[Deanna Earley]

Post by David Cox
I have also changed the code to check for no date, I don't want to allow no

Minor point, but the value of 0 is a valid date :)
It just happens to be a common sentinel value.

?format(0,"long date")
30 December 1899

I feel sorry for anyone celebrating their 113th birthday last Sunday and
how much hassle they must have with computers :p