Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.basic.visual.misc > #1689 > unrolled thread

Dates and Regional settings

Back to article view | Back to comp.lang.basic.visual.misc

Contents

  Dates and Regional settings "David Cox" <d.cox@hushmail.com> - 2013-01-01 19:38 -0600
    Re: Dates and Regional settings ralph <nt_consulting@yahoo.com> - 2013-01-01 20:49 -0600
      Re: Dates and Regional settings "David Cox" <d.cox@hushmail.com> - 2013-01-01 21:16 -0600
        Re: Dates and Regional settings ralph <nt_consulting@yahoo.com> - 2013-01-01 22:25 -0600
    Re: Dates and Regional settings Dr J R Stockton <reply1300@merlyn.demon.co.uk.invalid> - 2013-01-03 19:13 +0000
      Re: Dates and Regional settings "David Cox" <d.cox@hushmail.com> - 2013-01-03 19:23 -0600
        Re: Dates and Regional settings Deanna Earley <dee.earley@icode.co.uk> - 2013-01-04 09:47 +0000

#1689 — Dates and Regional settings

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? 

[toc] | [next] | [standalone]

#1690

On Tue, 1 Jan 2013 19:38:53 -0600, "David Cox" <d.cox@hushmail.com>
wrote:

>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? 
>

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

[toc] | [prev] | [next] | [standalone]

#1691

As Long
>>    Sale

"ralph" <nt_consulting@yahoo.com> wrote in message 
news:3l67e81isqecup3nnk3h64ggdbe0s52iu8@4ax.com...
> 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> 

[toc] | [prev] | [next] | [standalone]

#1692

On Tue, 1 Jan 2013 21:16:35 -0600, "David Cox" <d.cox@hushmail.com>
wrote:

>As Long
>>>    Sale
>
>"ralph" <nt_consulting@yahoo.com> wrote in message 
>news:3l67e81isqecup3nnk3h64ggdbe0s52iu8@4ax.com...
>> 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> 
>

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

[toc] | [prev] | [next] | [standalone]

#1693

In comp.lang.basic.visual.misc message <kc033i$rcg$1@dont-email.me>,
Tue, 1 Jan 2013 19:38:53, David Cox <d.cox@hushmail.com> posted:

>
>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.

[toc] | [prev] | [next] | [standalone]

#1694

"Dr J R Stockton" <reply1300@merlyn.demon.co.uk.invalid> wrote in message 
news:sdx9cmFThd5QFwHA@invalid.uk.co.demon.merlyn.invalid...
> In comp.lang.basic.visual.misc message <kc033i$rcg$1@dont-email.me>,
> Tue, 1 Jan 2013 19:38:53, David Cox <d.cox@hushmail.com> posted:
>
>>
>>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 

[toc] | [prev] | [next] | [standalone]

#1695

On 04/01/2013 01:23, David Cox wrote:
> I have also changed the code to check for no date, I don't want to allow no
> date by checking Int(NewVal)=0:

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

-- 
Deanna Earley (dee.earley@icode.co.uk)
i-Catcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored. Please reply to the 
group.)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.basic.visual.misc

csiph-web