61533 about xojo 2019r31 Web Client Date

This case was closed but. Web Client date is not working when implementing you will get the server date. This is not client date. Whatever we have Hashtags and can build around. But thats not a foundation for telling “not enough informations, feedback case closed”. This is ignoring facts.

Does using GMTOffset work?

dateproperty.GMTOffset=Session.GMTOffset

nope. It is not.

The case was closed as Not Actionable because we requested a sample project and you said you wouldn’t provide one. I have yet to see an example project that shows the problem you are having.

Place this in the Shown Event of a WebLabel Report what it shows

Blockquote
dim dtclient as New Date

dtclient.GMTOffset=Session.GMTOffset

me.Text=dtclient.SQLDateTime

Blockquote

Okay. We are here not “normal” Computer Users. As an experienced C++ and Java Programmer it will be no Problem for me to test a functionality like this. So it should not be a Problem for xojo to get the same result out: if the client has no connection to a time server there will not be any chance to get the date with client date cause the function is not working at all. There is no need for a samplfe project cause all possible implementations where tested at our test center. So I have no chance for an example project if there is no functionality at all. This is documented here as xojo case since 2018 so I guess it aill not be to complex to test if this function is working well.

Way to the error as example: take a raspberry Pi as a server and do not set correct time and date. Connect a client with the correct date and time and try to get the Client date and time. You will see that xojo is giving the server time back. So not the client time. In all cases this behavior was coming up.

In this day and age, if a computer isn’t regularly connecting to a time server, all kinds of bad things start to happen.

The reality is that we had two choices

  1. Use the server time and apply the browser’s GMT offset
  2. Transmit the client time to the server periodically.

We chose the former because:

  1. It’s likely to be correct
  2. The alternative would be to periodically send the time from the client, taking latency into account and remembering when we received that data so we could calculate something close to what the clients time is… which most of the time would be within a few seconds of the server time ± GMT Offset.