Forzare la localizzazione del fuso orario in un progetto

[vuott]

Vorrei riportare questa discussione apparsa nella M.L.I.:

« 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.
--
Kevin Fishburne  »


« 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,

--
Benoît Minisini  »

[vuott]

Segue:

« 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. The client OS is
UTC/GMT -5 (US Eastern). 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$? 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.

--
Kevin Fishburne »


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

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 »

[vuott]

...segue ancora...


« Isn't unix time independent of timezones (it always uses UTC)?
Can you use it?

$ date +%s

Jussi »

« OK... You must understand that Gambas stores all date/time in UTC
internally. The timezone is applied only when converting that date/time
to a string.

So you can safely exchange date/time between your client and your server
by using the WRITE instruction or by converting the date/time to a
number with CFloat() before exchanging it.

Regards,

--
Benoît Minisini »


« The date/time is sent/received as a float and stays synchronized. The
problem is (as you say) when the float is converted to a string the time
zone is applied. I need a way to print

Format$(CDate(DateCurrent), "mmmm d, yyyy, hh:nn:AM/PM")

without the time zone being applied, or with a specific TZ applied.
"DateCurrent" is the float. I'm trying not to custom create a calendar
and complicate Format$ with it, but specify a time zone. The server is
fine, but the client applies local TZ and DST rules and fouls the
formatting of Format$.

Hope that makes sense, and thanks.

Kevin Fishburne »


« Presumably the float is seconds since epoch or similar.
so calculate the difference between the local time and server time in seconds
and subtract it from the float value before display, this
"counteracts" the time zone
adjustment applied by the client OS

Ian »


« To get the current timezone, you do Round(Frac(Date(Now)) * 24). Then
you can use this value to convert a date to/from UTC.

Regards,

--
Benoît Minisini »


« So scatterbrained... I have added System.TimeZone property for a while.
It returns the interval with UTC in seconds (for example, -3600 in
France currently).

Regards,

--
Benoît Minisini »