On Tue, Feb 7, 2012 at 10:06 AM, Fred Taylor wrote:
> Any body know of a way to intercept the returns from DATE(), DATETIME(),
> TIME() etc. for different timezones WITHOUT changing the Windows setting
> for timezone?
>
> We've moved a bunch of applications to the cloud and now have users
> access
Fred
If you DO have to change the calls I would recommend that you take a look at
GoFish available on Codeplex ... you would be able to globally change DateTime(
to MyDateTime( etc and then try to achieve what you need in the custom
functions MyDateTime(), MyDate(), and MyTime()
Paul
-Ori
Thanks Paul. That may be the route that has to be taken. I'm just not
that comfortable with that massive a change.
Fred
On Tue, Feb 7, 2012 at 9:16 AM, Paul Newton wrote:
> Fred
>
> If you DO have to change the calls I would recommend that you take a look
> at GoFish available on Codeplex ...
Fred Taylor wrote on 2012-02-07:
> Thanks Paul. That may be the route that has to be taken. I'm just not
> that comfortable with that massive a change.
>
> Fred
>
>> We've moved a bunch of applications to the cloud and now have users
>> accessing from multiple timezones, but the applicatio
, February 7, 2012 2:45 PM
>Subject: Re: Any way to alter the time returned by windows for DATETIME()?
>
>Thanks Paul. That may be the route that has to be taken. I'm just not
>that comfortable with that massive a change.
>
>Fred
>
>
>On Tue, Feb 7, 2012 at 9:16 AM,
On 2/7/12 8:06 AM, Fred Taylor wrote:
> if we have to change the
> calls to DATE(), DATETIME(), etc. to use a different function. Most
> definitely not looking forward to 45K changes to code!
Automated changes, not manual, right? There are tools for that.
Paul
_
Absolutely.
Fred
On Tue, Feb 7, 2012 at 10:28 AM, Paul McNett wrote:
> On 2/7/12 8:06 AM, Fred Taylor wrote:
> > if we have to change the
> > calls to DATE(), DATETIME(), etc. to use a different function. Most
> > definitely not looking forward to 45K changes to code!
>
> Automated changes, n
It's just plain old VFP updating tables. The problem is that a user from
EST zone stamps a record at say 11:00 AM local time. A user from PST
stamps a record at 10:00 AM local time (1:00 PM EST). The 10:00 AM time is
in the change queue as before the 11 AM entry, even though it occurred
later.
>Sent: Tuesday, February 7, 2012 2:45 PM
> >Subject: Re: Any way to alter the time returned by windows for DATETIME()?
> >
> >Thanks Paul. That may be the route that has to be taken. I'm just not
> >that comfortable with that massive a change.
> >
> >F
Fred Taylor wrote on 2012-02-07:
> Thanks Eurico, that looks like what's got to be done a mass change. Code
> is being written to handle an offset to the VFP local time to make
> everything consistent again.
>
> Fred
>
Fred,
I found some code a few years back on the foxwiki to determine
On 2/7/2012 1:34 PM, Fred Taylor wrote:
> It's just plain old VFP updating tables. The problem is that a user from
> EST zone stamps a record at say 11:00 AM local time. A user from PST
> stamps a record at 10:00 AM local time (1:00 PM EST). The 10:00 AM time is
> in the change queue as before t
I handle times from all round the world. Everything is saved in UTC (GMT) so
there can be no problems.
Allen
-Original Message-
From: Fred Taylor
Sent: Tuesday, February 07, 2012 7:36 PM
To: profoxt...@leafe.com
Subject: Re: Any way to alter the time returned by windows for DATETIME
On Tue, Feb 7, 2012 at 12:42 PM, Tracy Pearson wrote:
> Fred Taylor wrote on 2012-02-07:
> > Thanks Eurico, that looks like what's got to be done a mass change.
> Code
> > is being written to handle an offset to the VFP local time to make
> > everything consistent again.
> >
> > Fred
> >
>
>
essage-
> From: Fred Taylor
> Sent: Tuesday, February 07, 2012 7:36 PM
> To: profoxt...@leafe.com
> Subject: Re: Any way to alter the time returned by windows for DATETIME()?
>
> Thanks Eurico, that looks like what's got to be done a mass change. Code
> is being written
No, the only thing is that all postings be for the same timezone. That
will solve the issues for now.
Fred
On Tue, Feb 7, 2012 at 12:48 PM, MB Software Solutions, LLC <
mbsoftwaresoluti...@mbsoftwaresolutions.com> wrote:
> On 2/7/2012 1:34 PM, Fred Taylor wrote:
> > It's just plain old VFP upd
Airlines have been doing it that long, well I think so. I will ask a friend
who knows.
Al
-Original Message-
From: Fred Taylor
Sent: Tuesday, February 07, 2012 9:01 PM
To: profoxt...@leafe.com
Subject: Re: Any way to alter the time returned by windows for DATETIME()?
If only they had
do you use a HTML/JS user interface?
If so you could add some JS on form.submit() to convert date and time to
UTC, and do the other way round when response comes in.
this way you would have consistent UTC dates on your back end
Thierry Nivelet
FoxInCloud
Give your VFP app. a new life in the cloud
All stock VFP. No html/js.
Fred
On Tue, Feb 7, 2012 at 1:27 PM, Thierry Nivelet wrote:
> do you use a HTML/JS user interface?
> If so you could add some JS on form.submit() to convert date and time to
> UTC, and do the other way round when response comes in.
> this way you would have consisten
Most of the replacements should be fixed with an easy
#define date mydate
#define datetime mydatetime
This wouldn't affect any dynamically created code, though.
Christof
___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com
Hi Christof,
I thought of doing that, but can you use #DEFINE in a report? The biggest
problem I see with #DEFINE would be making sure all the code was covered,
especially in the screens/classes.
Not sure if there's any dynamic code with those functions.
Fred
On Tue, Feb 7, 2012 at 11:26 PM,
To get the users' local time zone for your mydatetime() pinch some code
from:
http://support.microsoft.com/kb/194576
AndyD 8-)#
___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free versio
That will come in handy, thanks!
But getting the user's local time is not the problem, it's posting things
according to the application's time that's the issue. Kind of hard to
explain (hard enough keeping it straight in my head!) with all the
different app requirements, users from multiple locat
On Wed, Feb 8, 2012 at 10:42 AM, Fred Taylor wrote:
> That will come in handy, thanks!
>
> But getting the user's local time is not the problem, it's posting things
> according to the application's time that's the issue. Kind of hard to
> explain (hard enough keeping it straight in my head!) with
Would be nice to have such things as columns to handle this. These
applications are way too old to put that much effort into it.
They're all getting replaced soon (ha!) with a .NET web app (3+ years late
already).
Fred
On Wed, Feb 8, 2012 at 10:02 AM, Stephen Russell wrote:
> On Wed, Feb 8, 2
On Wed, Feb 8, 2012 at 11:07 AM, Fred Taylor wrote:
> Would be nice to have such things as columns to handle this. These
> applications are way too old to put that much effort into it.
>
> They're all getting replaced soon (ha!) with a .NET web app (3+ years late
> already).
>
---
On Feb 8, 2012, at 10:42 AM, Fred Taylor wrote:
> But getting the user's local time is not the problem, it's posting things
> according to the application's time that's the issue. Kind of hard to
> explain (hard enough keeping it straight in my head!) with all the
> different app requirements, us
On Wed, Feb 8, 2012 at 11:17 AM, Ed Leafe wrote:
> On Feb 8, 2012, at 10:42 AM, Fred Taylor wrote:
>
>> But getting the user's local time is not the problem, it's posting things
>> according to the application's time that's the issue. Kind of hard to
>> explain (hard enough keeping it straight in
On Wed, Feb 8, 2012 at 10:17 AM, Ed Leafe wrote:
> On Feb 8, 2012, at 10:42 AM, Fred Taylor wrote:
>
> > But getting the user's local time is not the problem, it's posting things
> > according to the application's time that's the issue. Kind of hard to
> > explain (hard enough keeping it straigh
On Wed, Feb 8, 2012 at 10:15 AM, Stephen Russell wrote:
> On Wed, Feb 8, 2012 at 11:07 AM, Fred Taylor wrote:
> > Would be nice to have such things as columns to handle this. These
> > applications are way too old to put that much effort into it.
> >
> > They're all getting replaced soon (ha!) w
On Feb 8, 2012, at 11:23 AM, Fred Taylor wrote:
> Ed I agree 1000%. But these apps were originally developed 18 years ago.
> No reason to think of such things then. It's amazing they were even Y2K
> compliant!
Time zones existed 18 years ago! :)
What I'm saying is that as you
On Wed, Feb 8, 2012 at 10:28 AM, Ed Leafe wrote:
> On Feb 8, 2012, at 11:23 AM, Fred Taylor wrote:
>
> > Ed I agree 1000%. But these apps were originally developed 18 years ago.
> > No reason to think of such things then. It's amazing they were even Y2K
> > compliant!
>
> Time zones exi
On Wed, Feb 8, 2012 at 11:45 AM, Fred Taylor wrote:
>
> Time zones existed back then, but the app and the users were only in one.
> Even when the user base expanded, the app still only ran in one place, and
> the far flung users ran it using remote desktop. They still had their
> Outlook and ot
Fred Taylor wrote:
>
> All the clever ideas were immediately trashed soon after their suggestion.
> Some of those were even my ideas!
>
> Fred
>
>
>
Could you not go back to using a TS connection even though the data is
now in the cloud? That would buy you some time.
Peter
We receive various formatted dates/times from all over. Times were noted
as to their source and converted as needed to the local time of the app.
The problem now is that the app is seeing multiple local times, which it
never did before. This app existed the way it is long before I got here.
Fre
On 02/08/12 09:45, Fred Taylor wrote:
> We're discussing the options this afternoon. But as with all things in the
> programming world, the fix is needed yesterday!
>
> All the clever ideas were immediately trashed soon after their suggestion.
> Some of those were even my ideas!
>
> Fred
Hi, Fr
On Wed, Feb 8, 2012 at 5:32 PM, Dan Covill wrote:
> On 02/08/12 09:45, Fred Taylor wrote:
> > We're discussing the options this afternoon. But as with all things in
> the
> > programming world, the fix is needed yesterday!
> >
> > All the clever ideas were immediately trashed soon after their
>
If programming was easy, everybody would be doing it.
From: Dan Covill
To: ProFox Email List
Sent: Wednesday, February 8, 2012 7:32 PM
Subject: Re: Any way to alter the time returned by windows for DATETIME()?
On 02/08/12 09:45, Fred Taylor wrote:
> We
way to alter the time returned by windows for DATETIME()?
On 02/08/12 09:45, Fred Taylor wrote:
> We're discussing the options this afternoon. But as with all things
> in the programming world, the fix is needed yesterday!
>
> All the clever ideas were immediately trashed
On 02/10/12 01:17, AndyD wrote:
> I assume this is some sort of time-stamp stored in a dbf so how are you
> suggesting the UTC is saved? (DateTime does not recognise time zone or
> milliseconds according to Help! )
> AndyD 8-)₹
No, the UTC (Universal Time, Coordinated) is just a date or date/tim
I assume this is some sort of time-stamp stored in a dbf so how are you
suggesting the UTC is saved? (DateTime does not recognise time zone or
milliseconds according to Help! )
AndyD 8-)₹
On 19:59, Dan Covill wrote:
>
> I'm with Ed, any solution has to start with saving the UTC. And don't
> u
OK - thanks for the reply - I already posted a link to a win API call
for getting the time zone (and saving flag).
AndyD 8-)₹
On 19:59, Dan Covill wrote:
> On 02/10/12 01:17, AndyD wrote:
>> I assume this is some sort of time-stamp stored in a dbf so how are you
>> suggesting the UTC is saved? (
41 matches
Mail list logo
