Date & Time format issue

#1

Hi,

I seem to have bumped into something wierd... don't know what im
missing.

(Filemaker Pro 7.0v3)

GetAsText(Date(6,30,2005)) yields 30/6/2005

the 'file' is set to d/m/yyyy
but
the 'system' is set to m/d/yyyy

File Options -> Text -> Data Entry is set to Always use System Settings
Format -> Use System System Formats is checked. And date fields with no
special formatting applied are displaying as m/d/yyyy.

So shouldn't GetAsText('Date') be returning m/d/yyyy??? If not, why not?
And more importantly, how do you make it respect the system settings??

Its causing some problems in a script that uses insert calculated result
to create a date range... its inserting a text string:

1/6/2005..1/30/2005 and filemaker rejects it because the system is set
to US and want it as 6/1/2005...6/30/2005.

Obviously I can change the file to US by cloning and reimporting, but
that's a pile of work, and should be unncessary. More importantly it
doesn't solve the problem, as its likely to break again as soon as
someone running a system set to d/m/yyyy tries to use it.
-thanks

#2

A suggestion and a couple questions:

1) Try using the script step 'Set Use System Formats [On]. Not sure if
this will behave any differently from the File Options setting.

2) Are you sure it is being stored in dd/mm/yyyy, or perhaps the field's
formatting on the actual layout just happens to be custom-set for
dd/mm/yyyy?

3) Is it that the date on all records is coming up wrong, only on older
records, only on newly entered records, etc?

42 wrote:

Quote:

Hi,

I seem to have bumped into something wierd... don't know what im
missing.

(Filemaker Pro 7.0v3)

GetAsText(Date(6,30,2005)) yields 30/6/2005

the 'file' is set to d/m/yyyy
but
the 'system' is set to m/d/yyyy

File Options -> Text -> Data Entry is set to Always use System Settings
Format -> Use System System Formats is checked. And date fields with no
special formatting applied are displaying as m/d/yyyy.

So shouldn't GetAsText('Date') be returning m/d/yyyy??? If not, why not?
And more importantly, how do you make it respect the system settings??

Its causing some problems in a script that uses insert calculated result
to create a date range... its inserting a text string:

1/6/2005..1/30/2005 and filemaker rejects it because the system is set
to US and want it as 6/1/2005...6/30/2005.

Obviously I can change the file to US by cloning and reimporting, but
that's a pile of work, and should be unncessary. More importantly it
doesn't solve the problem, as its likely to break again as soon as
someone running a system set to d/m/yyyy tries to use it.
-thanks

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg (818) 883-2846
FM Pro Solutions Los Angeles, California

FileMaker 7 Certified Developer
Associate Member, FileMaker Solutions Alliance

#3

In article <11cqu69tjvhio9b (AT) corp (DOT) supernews.com>,
howard (AT) antispahm (DOT) fmprosolutions.com says...

Quote:

A suggestion and a couple questions:

1) Try using the script step 'Set Use System Formats [On]. Not sure if
this will behave any differently from the File Options setting.

I hadn't noticed that script step. Thanks! Sadly after some testing it
turns out its actually just a script way to to toggle the Format->Use
System Settings checkbox, which was already set correctly. (To use
system settings)

Quote:

2) Are you sure it is being stored in dd/mm/yyyy, or perhaps the field's
formatting on the actual layout just happens to be custom-set for
dd/mm/yyyy?

3) Is it that the date on all records is coming up wrong, only on older
records, only on newly entered records, etc?

No date fields are being used.

I've boiled it down to the point that there is no actual date field in
play here.Its a global TEXT field that is set via script to:

SetField Global_Text =

GetAsText(Date(6;1;2005))&".."&GetAsText(Date(6;1; 2005))

Given that the system settings are US (M/D/Y), and the software is set
to use system settings this should return:

6/1/2005..6/30/2005, but is instead ignoring the system settings, and
using the file settings, and returning 1/6/2005..30/6/2005

Quote:

42 wrote:
Hi,

I seem to have bumped into something wierd... don't know what im
missing.

(Filemaker Pro 7.0v3)

GetAsText(Date(6,30,2005)) yields 30/6/2005

the 'file' is set to d/m/yyyy
but
the 'system' is set to m/d/yyyy

File Options -> Text -> Data Entry is set to Always use System Settings
Format -> Use System System Formats is checked. And date fields with no
special formatting applied are displaying as m/d/yyyy.

So shouldn't GetAsText('Date') be returning m/d/yyyy??? If not, why not?
And more importantly, how do you make it respect the system settings??

Its causing some problems in a script that uses insert calculated result
to create a date range... its inserting a text string:

1/6/2005..1/30/2005 and filemaker rejects it because the system is set
to US and want it as 6/1/2005...6/30/2005.

Obviously I can change the file to US by cloning and reimporting, but
that's a pile of work, and should be unncessary. More importantly it
doesn't solve the problem, as its likely to break again as soon as
someone running a system set to d/m/yyyy tries to use it.
-thanks

#4

42 wrote:

Quote:

Hi,

I seem to have bumped into something wierd... don't know what im
missing.

(Filemaker Pro 7.0v3)

GetAsText(Date(6,30,2005)) yields 30/6/2005

the 'file' is set to d/m/yyyy
but
the 'system' is set to m/d/yyyy

File Options -> Text -> Data Entry is set to Always use System
Settings Format -> Use System System Formats is checked. And date
fields with no special formatting applied are displaying as m/d/yyyy.

So shouldn't GetAsText('Date') be returning m/d/yyyy??? If not, why
not? And more importantly, how do you make it respect the system
settings??

Its causing some problems in a script that uses insert calculated
result to create a date range... its inserting a text string:

1/6/2005..1/30/2005 and filemaker rejects it because the system is
set to US and want it as 6/1/2005...6/30/2005.

Obviously I can change the file to US by cloning and reimporting, but
that's a pile of work, and should be unncessary. More importantly it
doesn't solve the problem, as its likely to break again as soon as
someone running a system set to d/m/yyyy tries to use it.
-thanks
=======

According to the FMP7 help file the format of the result of
Date(month;day;year) depends on the date format in use when the
database file was created - which I take to mean that you have no
control over it once the file is created. So within a script I guess
that means you have to ensure you are using file formats as opposed to
system formats. It is not clear what would happen if you were to clone
the file. Does that actually change the file formats?

#5

In article <0KSdnRuWzNjTNFDfRVnyvg (AT) brightview (DOT) com>, agent (AT) owlsnet (DOT) co.uk
says...

Quote:

According to the FMP7 help file the format of the result of
Date(month;day;year) depends on the date format in use when the
database file was created - which I take to mean that you have no
control over it once the file is created.

You can't change the internal storage, but via the various "Use system
settings" options you can have filemaker conform to the users preference
for display/entry/and validation in every case but, it seems, this one.

Quote:

So within a script I guess
that means you have to ensure you are using file formats as opposed to
system formats.

A script that computes default find criteria and then presents it to the
user for acceptance or modification should be able to conform to the
users regional settings.

Quote:

It is not clear what would happen if you were to clone
the file. Does that actually change the file formats?

Yes.

But that doesn't allow you to write code that supports simultaneous
users with different regional settings/preferences. (a common enough
occurence, particularly in europe or canada)

#6

42 wrote on 07/07/2005 - 23:27:05

Quote:

In article <0KSdnRuWzNjTNFDfRVnyvg (AT) brightview (DOT) com>,
agent (AT) owlsnet (DOT) co.uk says...

According to the FMP7 help file the format of the result of
Date(month;day;year) depends on the date format in use when the
database file was created - which I take to mean that you have no
control over it once the file is created.

You can't change the internal storage, but via the various "Use
system settings" options you can have filemaker conform to the users
preference for display/entry/and validation in every case but, it
seems, this one.

So within a script I guess
that means you have to ensure you are using file formats as opposed
to system formats.

A script that computes default find criteria and then presents it to
the user for acceptance or modification should be able to conform to
the users regional settings.

It is not clear what would happen if you were to clone
the file. Does that actually change the file formats?

Yes.

But that doesn't allow you to write code that supports simultaneous
users with different regional settings/preferences. (a common enough
occurence, particularly in europe or canada)
=======

(This is actually David again - I posted with the wrong identity last
time!)

I am talking bout a fudge to get round FMP deficiency.

Do you by any chance have the two dates that you are using for the ends
of the range find sitting on a layout as you set up the find? I have
discovered that Copy and Paste (not recommended I know) in fact retain
the system format so you can use a script to build up the search
criterion by Copy and Paste the first date then Insert Text ... and
finally Copy and Paste the second date (do not select the field at each
paste so that these bits are appended). I'm in the UK and I have tried
this with my usual settings and by changing my settings to English(US)
and each time it produces the range in the correct format for the
system settimgs.

--
Dan Fretwell
Using FMP7.03 on WinXP SP2

#7

In article <xn0e4hmc1xhtez000 (AT) news (DOT) freenetname.co.uk>, dan (AT) owlsnet (DOT) co.uk
says...

Quote:

42 wrote on 07/07/2005 - 23:27:05

In article <0KSdnRuWzNjTNFDfRVnyvg (AT) brightview (DOT) com>,
agent (AT) owlsnet (DOT) co.uk says...

According to the FMP7 help file the format of the result of
Date(month;day;year) depends on the date format in use when the
database file was created - which I take to mean that you have no
control over it once the file is created.

You can't change the internal storage, but via the various "Use
system settings" options you can have filemaker conform to the users
preference for display/entry/and validation in every case but, it
seems, this one.

So within a script I guess
that means you have to ensure you are using file formats as opposed
to system formats.

A script that computes default find criteria and then presents it to
the user for acceptance or modification should be able to conform to
the users regional settings.

It is not clear what would happen if you were to clone
the file. Does that actually change the file formats?

Yes.

But that doesn't allow you to write code that supports simultaneous
users with different regional settings/preferences. (a common enough
occurence, particularly in europe or canada)
=======

(This is actually David again - I posted with the wrong identity last
time!)

I am talking bout a fudge to get round FMP deficiency.

Do you by any chance have the two dates that you are using for the ends
of the range find sitting on a layout as you set up the find? I have
discovered that Copy and Paste (not recommended I know) in fact retain
the system format so you can use a script to build up the search
criterion by Copy and Paste the first date then Insert Text ... and
finally Copy and Paste the second date (do not select the field at each
paste so that these bits are appended). I'm in the UK and I have tried
this with my usual settings and by changing my settings to English(US)
and each time it produces the range in the correct format for the
system settimgs.

Ah...

So instead of relying on the GetAsText('date') function to convert dates
to text, I could instead push the dates into a date field, and then use
copy & paste to grab the 'text' of those dates, correctly formated.

Its crazy enough it just might work.

Thanks... this definately is an ugly workaround, but yeah, it should do
the trick. I don't currently have these dates in a field, but its simple
enough to create a global and run push them through it.

I'm of the opinion that while its not an outright bug, FM should provide
a GetAsText function that respects the user's choice of using the file
or system settings.

Oh well maybe it will be in version 8.

I shouldn't complain. At least copy&paste works. Well except for table
definitions and script steps of course.

Maybe for v8 they'll at least finish implementing copy and paste.

/ducks

#8

42 wrote on 7/8/2005 - 1:13:08 AM

<SNIP>.

Quote:

Oh well maybe it will be in version 8.

I shouldn't complain. At least copy&paste works. Well except for
table definitions and script steps of course.

Maybe for v8 they'll at least finish implementing copy and paste.

/ducks

=======

Whoa, save something for version 9!

--
Dan Fretwell
Using FMP7.03 on WinXP SP2

#9

42 wrote:

Quote:

I'm of the opinion that while its not an outright bug, FM should provide
a GetAsText function that respects the user's choice of using the file
or system settings.

If I were you, I would report it as a bug at
<http://filemaker.com/company/product/problems.html>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg (818) 883-2846
FM Pro Solutions Los Angeles, California

FileMaker 7 Certified Developer
Associate Member, FileMaker Solutions Alliance

#10

In article <11csqoiab65t791 (AT) corp (DOT) supernews.com>,
howard (AT) antispahm (DOT) fmprosolutions.com says...

Quote:

42 wrote:

I'm of the opinion that while its not an outright bug, FM should provide
a GetAsText function that respects the user's choice of using the file
or system settings.

If I were you, I would report it as a bug at
http://filemaker.com/company/product/problems.html

Yeah, on reconsideration, I will.

I initially felt it was important to have a function that could be
relied upon to return a consistent format for parsing reasons, but that
should be accomplishable with the UseSystemSettings script step and
GetAsText should respect that preference.