Date-Time Problem in Canada

[ChewDoggie]

Hello All,

I have an application that I developed here in the US but is being installed and ran in Canada. They're experiencing a problem with the Date-time functions in the application. I have an ini file where the application retrieves and stores a "last ran date/time" string.

I don't really know what the exact date/time format is up there. How can I get this system-date/time information ?

BTW, the date-time in the ini file is being compared to the "now" command in vb6, not a database date/time.

Chew




10% of your life is what happens to you. 90% of your life is how you deal with it.

 

[SkipVought]

hi,

They're experiencing a problem with the Date-time functions in the application.

Exactly what is the problem?

Skip,
[sub]
Just traded in my old subtlety...
for a NUANCE![/sub]

 

[dilettante]

Use Format$() to format date/time values for persistent storage:

The universal date format is #yyyy-mm-dd hh:mm:ss#. However, both the date component (#yyyy-mm-dd#) and the time component (#hh:mm:ss#) can be represented separately.

Use Str$() and Val() for numeric values that might contain a decimal point.

 

[HughLerwill]

>I don't really know what the exact date/time format is up there

You can checkout the defaults via Windows Control panel - Regional settings. I seem to remember Canadian settings are very similar to those here in the UK; dates use dd mm yy style formats and they use '.' as the decimal delimiter.

 

[chelseatech]

Most of the world uses D/M/Y as a date presentation format. For outside the US assume that.


Editor and Publisher of Crystal Clear

http://www.chelseatech.co.nz/pubs.htm

 

[Bluejay07]

As with any computer anywhere in the world, the date is, for the most part, user/organization preferred, not specifically region based.
I live in Canada and I prefer M/D/Y format personally.

If at first you don't succeed, then sky diving wasn't meant for you!

 

[dilettante]

For persisted settings though you don't want to conform to local conventions. For example anything in an installed INI would have to be localized during installation, which isn't necessary. These are not values meant for user interaction.

Saving settings in a binary format would be preferable to eliminate ambiguity, but this isn't always practical or desireable. This is why we have universal formats for dates and numerics persisted as strings. It becomes even more important when data might be exchanged over networks because the networks might span localities.


VB6 has Write# and Input# for similar reasons. Values are always read/written using universal formats instead of localized ones. This makes it possible to interchange files created this way across locales.

 

[ChewDoggie]

I love this forum! I lost my Broadband Internet connection and just got it back.

Thanks to all who replied.

It turned out that one area of my app, I was doing some manual formatting of date/time that contained "AM" or "PM" indicators and that was the problem. WHen I replaced it with simple Now function, the DateAdd and Date comparisons worked as expected. Amateurish on my part.

Dilettante got it right, they use, what I call, military time, i.e., "2010-08-26 13:00:00"

Thanks to All !

Got another question coming in a separate thread.

Chew

10% of your life is what happens to you. 90% of your life is how you deal with it.

 

[Hypetia]

My suggestion, don't use the default ambigious format.

When writing to ini file, format the output in a format which is not affected by the locale, for example "dd-mmm-yy hh:nn:ss".

When a date string formatted like this is read back, it is always correct, no matter which locale you are using.

 

[JoeAtWork]

I second Hypetia on that, never use ambigious formats for dates. This is not a US vs. Canada thing. The guy across the street might be using a different short date format than you are.