[Gambas-user] forcing time zone localization

[Bruce]

Kevin,
 Some thoughts expresed inline.

On Fri, 2013-02-01 at 02:37 -0500, Kevin Fishburne wrote:
> On 01/31/2013 04:29 AM, Benoît Minisini wrote:
> > Le 31/01/2013 08:35, Kevin Fishburne a écrit :
> >> I have a client/server application in which the server tells the client
> >> the date and time. The date and time is calculated by the server from an
> >> arbitrary starting point and at an arbitrary scale, but based on the
> >> server's system clock so that time still "advances" when the server
> >> application is not running. The client and server display the date and
> >> time using code like this:
> >>
> >> Format$(CDate(DateCurrent), "mmmm d, yyyy, hh:nn:AM/PM")
> >>
> >> I need Gambas to use a specific time zone for the client and server,
> >> ignoring the system time zone. I've read this:
> >>
> >> http://gambasdoc.org/help/doc/locale?v3
> >>
> >> Is what I'm trying to do possible? What environment variable should I
> >> set in Gambas ($LC_ALL, $LANG), and is there an ISO or table of codes to
> >> choose from? I've looked at ISO 3166 here:
> >>
> >> http://en.wikipedia.org/wiki/ISO_3166
> >>
> >> Thanks.
> >>
> > You should not need to use a different timezone for a program. Otherwise
> > you can use the TZ environmental variable.
> >
> > But you can get the current timezone by doing: Round(Frac(Date(now)) *
> > 24). (Meaning that the time is UTC + that value. TZ is set with the
> > opposite).
> >
> > Then you can convert a local time to GTM time for your communication
> > between server and client.
> >
> > Dunno if it fits your need.
> >
> > Regards,
> >
> 
> Just spent two hours on this with no success. I have the server's OS set 
> to use Venezuela's time zone because it has no DST. 

Server time probably should be UTC.  This makes the time calcs a bit
simpler.
  
> The client OS is 
> UTC/GMT -5 (US Eastern). 

Is the client system clock really set to UTC -5 or is it running UTC?
What I mean is that you seem to be trying to interpret how the OS (aka
Now() in gambas, which is going to return the localized time according
to *important* the user's own time settings).
   
> The client and server start with the same raw 
> date/time obtained through CFloat(Now) on the server. The client's 
> date/time is different than the server's by 30 minutes due to 
> localization used by Format$.
> 
> I created a TZ environment variable and regardless of its value it has 
> no effect on the output of Format$. Is the TZ environment variable 
> ignored or not used by Format$? 

TZ= is only one of the possible *user* env settings that controls how
the "time" is interpreted from the OS time.  Some distros us TZ but
other distros use other env settings.

> There may be a solution staring me in 
> the face based on the information you gave me, but I can't see it 
> despite my efforts. The really stupid way to solve the problem would be 
> to set the client and server OS time zones to be the same, but that 
> would correctly inform the user that I was an idiot. ;)

No, setting the client and server OS to UTC and letting the stuff above
the OS is the simplest way (hahaha!) to solve how the "time" is shown to
the user... in their environment.

Now a game situation, where the game time is *represented* according to
the game logic, and not the user's time frame, is a very different thing
to trying to break your balls converting the local (server or client)
*represented* time to and from the actual OS time and the *user seen*
time.

The central gist is,
a) decide on a time reference, from what you have posted I would tend
towards the server OS running UTC (or if you really want to go crazy,
try running it's clock in siderial time... nah, you probably don't want
to do that.)
b) thus UTC is the frame for all events and therefore there is a lot of
software around that can convert an "event time", as seen in the servers
time reference, to a local time on the client machine ***important*** at
the OS level.
c) the problem then becomes one of ensuring that the user's
"represented" time in your gambas app  matches to their local mental
idea of time.


If that sounds crazy, then consider this.

We have, what I believe is a similar situation.  In Australia there are
about 14 or 15 local time zones, in the TZDATA sense.  Each state is
capable of setting the local time to the federally mandated and
generally recognized 4 time zones: "Lord Howe Island time", "Australian
Eastern Time", "Australian Central Time" and "Australian Western Time"
plus where they think the curtains wont fade, some states use daylight
saving time and some don't. In addition, there are some localities
within states that adopt a more pragmatic approach, where the local time
is based on the time in the locale where they do most of their business.

What drives me crazy is, in a lot of situations we may have a horse
auction say at 9:00am "Australian Central Time - Daylight Saving" in a
place called Lamaroo (google it) in South Australia.  I have a client
that lives 35km away, but they are in the state of Victoria in
"Australian Eastern Time" which does not recognize daylight savings.
They want to sell a horse at that auction.... allowing for 55 minutes
float time (sorry technical term, allowing that it will take 55 minutes
to load the horse in a trailer and drive to the auction 35 km away) ...
what time do they have to leave to make sure the horse is present for
the auction?

I wish I could share with you the atrocious code we have to get around
this but it is so localised to Australian time "regions" that it is
probably useless elsewhere. (And it's not very pretty!)

BUT!  The important bit is to get a hold on the difference between the
OS time frame and the local time frame and the user time frame.

I doubt it, but I seriously hope this helps.

Bruce