Issue with System Date and RTC

alsol

We currently working on a NAV RTC rollout across the world with one main server in Germany. The RTC access the server over WAN so no Citrix or Terminal Server is in use. I would assume that RTC uses the client's local date and time but it seems that NAV uses the server date. So when users are posting transactions after 6 PM Eastern US it automatically defaults to the next day.

Any idea how this could be changed? What is the approach of Microsoft with this issue?

raveendran.s

RTC executes the business logic in the middle tier. It picks up the date of that System's Date as Today.

This topic triggers another doubt for me :-k

Is it possible to have to middle Tier (NAV Server) for one DB and Different Clients associated to it (as shown in the attached image).

Sog

raveendran.s wrote:

RTC executes the business logic in the middle tier. It picks up the date of that System's Date as Today.

This topic triggers another doubt for me :-k

Is it possible to have to middle Tier (NAV Server) for one DB and Different Clients associated to it (as shown in the attached image).

Yes, yes you can. MS recommends it even to deploy it as such with 1 service tier per 40 users.

raveendran.s

Thank Mr Sog, With your response the solution for the actual query of this post can be as below.

1) German Users can connect to one Service Tier which is configured with German Time Zone

2) Other Users can connect to another Service Tier which is configured with other Time Zone...

Being Single Database the License and other Stuffs should be Shared...

Hope this should Possibly work...

alsol

Ok that makes sense. I will ask the hosting company to set it up accordingly.

What if there are different databases on the same instance? The license could be shared as well but might there be an issue with the service tier?

raveendran.s

On a SQL Instance, the Users Sessions are shared across the Databases.

And always the license count is based on the number sessions at SQL Level. Not based on the tunnels (I mean the Service Tiers).

ThomasHej_MSFT

Maybe I can add a little (actually a lot) background info to this.

Regarding time around the globe:

Rule #1: Life would be much easier if we all could agree to live by UTC and not "local" time.
Rule #2: Read rule #1

Jokes aside, this issue is really all about what the concept “local time” really means – and even answering this question is tricky, because it depend on the scenarios and inherently is ambiguous.

Example: Let’s assume I want to describe when a conference call between me and somebody in the US is about to take place, I would typically say 4PM Danish time, subtract 6 hours and tell them 10AM NewYork time. Everybody is happy, right?

Wrong! Suddenly it does not work anymore. EU and the US do not switch to summer time on the same dates. Suddenly the difference is no longer 6 hours but 5 or 7…

So, the solution is for all to use UTC… Unfortunately that won’t work either. Sometimes 11 o’clock means 11 o’clock no matter the time zone or possible shifts due to summer time issues.
Example: You rent a car and agree to return it next Tuesday at 11:00. If you call them and agree to extend the contract for one week. You will still think it as being Tuesday at 11:00 (although 7 days later), but if summertime change happens the Sunday in between, you actually are returning the car on a different UTC time. (Try showing up at 12:00 and tell that to AVIS)

Adding to the complexity is the fact that you can’t convert a “local” time to UTC time without knowing the “UTC difference”. That in turn requires you to know the country, date and the “Summer time rules”. Guess what… that now requires you to know the entire history of summer time rules and updated future ones.

The latter is actually “unsolvable”.

Example: Assuming that you are planning a future event on November 1st 2013 at 6PM in Denmark: Live video is expected and remote participants from all over the world are expected to join.
Although the conference center is booked at 6PM in Denmark, you - as good citizen - plan everything in UTC. 6PM “Danish local” will (given the date and the Danish summertime rules) get stored as 5PM UTC and people around the global can get their local time from that. Everybody is happy right?

Wrong! Now, after you send out the invitations, the Danish government suddenly decides to change the summer time rules so the summertime change happens after the event (this is not a theoretical example, it happens frequently – both EU and US has done this! – In other parts of the world war or local conflicts often results in regions changing time zones)

Now, all this requires all software to “know” that 6PM local on November 1st in year 2012 and before in Denmark corresponds to 5PM UTC, but starting from 2013, the same calculation should yield 4PM UTC.
And here comes the “unsolvable part”. What about persisted data that was calculated using “old” rules (done before the new rules are put into effect)?

Reading the UTC time from the database from our planned event above that was created using the old rules and using the “new” updated summertime rules, will yield the wrong local time (it will show 7PM)…

The only way to solve this is to register the ruleset that was used to do the conversion, track all changes and to store the Date+Time+Country+RulesetVersion+Ruleset when storing any UTC time. Yikes! As far as I know nobody does that (think about the size of a simple LocalTime type), and we all live with the resulting confusion.

Speaking of confusion: I could add the fact, that the “02:30AM local time” happens twice during the change from summer time, but I think I will stop here… You get the picture.

Now, where does that leave us? What is the guidance?

First of all, you need to separate which times are assumed to be local times, no need to store everything as UTC if it is not needed – improper use of UTC will yield other errors.

The reverse is also true. Always use UTC to store time that reflect a “timestamp” that are considered globally unique. If you are tracking when an item was produced use UTC if you expect the item to be sold outside your local time zone.

So, use Date and Time fields (they are always considered “local”) for non-global scenarios – and use DateTime (which is always using UTC to store itself) for global scenarios.

If you create DateTime fields on a page in NAV, the client will show the time in local time defined by the time zone info used on the client (and summertime rules distributed by windows update). The conversion is done on the client and the server will only “see” UTC DateTime. This ensures correctness as far as possible.

Running business logic on the server that converts from UTC to local (or vice versa) can be troublesome for all the above reasons and should only be done with considerations to the effects!