I got a legacy system(SQL Server DB) which holds date in plain date time format.
There is also a MS Dynamics CRM system which user interacts and inserts data to CRM DB. Data flows from legacy system to CRM.
The problem is CRM thinks all the data coming from legacy system is UTC formatted, in actual its a combination of GMT & BST plain date time values.
This results in some transactions time out of phase by an hour.
How should I tackle this problem?
The one solution I can think of is, to identify if the date falls under BST, subtract one hour from it and supply to CRM.
As BST = GMT + 1 hr and GMT and UTC are likely the same, thought this might solve the problem.
I'm not sure if I have ruled out all the possible issue with this problem.
Are there any alternative approaches?
Manipulating the difference & sending the UTC timestamp to CRM works fine.
Alternatively you can incorporate a new UTC field in legacy system & that can be used as offset value, so that sync between two systems.
Related
I'm currently using chronograf to view my point data in influxdb.
At first the queried results in chronograf seem abnormal to me but I have later worked out the issue to be at timezone differences.
So influxdb could only store data in UTC timezone but chronograf is using my local machine's timezone to display the data.
Example:
In influxdb I have a point sitting at 7PM on a particular day but when I tried to look it up in chronograf, it is saying timestamp for the same point is on 5PM.
Question:
Is there a way for me to set the default timezone for my chronograf? This is so that it will not try to tamper my data and be showing the original timestamp at UTC?
Short answer: It is not possible to display data in UTC in Chronograf 1.3 yet.
Chronograf by default offset influxdb's UTC data to whatever your local browser's time is.
I have raised a github issue to the Chronograf team and hopefully it will support displaying data in UTC soon.
See: https://github.com/influxdata/chronograf/issues/1960
Reference:
https://community.influxdata.com/t/chronograf-set-to-use-local-or-set-timezone/947
https://github.com/influxdata/chronograf/issues/1960
Install this add-on/extension for Chrome/Chromium
https://chrome.google.com/webstore/detail/change-timezone-time-shif/nbofeaabhknfdcpoddmfckpokmncimpj?hl=en
Install this add-on/extension for Firefox
https://addons.mozilla.org/en-US/firefox/addon/change-timezone-time-shift/
We're having a Weblogic Server on which we tried changing the time zone from current GMT to IST(GMT+5:30). This change led to the log file storing the right time zone.
However, the data displayed in the application too moved by GMT+5:30.
The application is expected to display the data with the time zone in which it was stored.
Are we missing something while changing the time zone of server?
No, this is application dependent, you may have to configure the application as well.
In general though, it's not a bad idea to keep servers in GMT no matter where they are located.
I have an iOS application and a rails backend.
The iOS client allows user to pick Dates in the (Year|Month|Day) format. No time is necessary, it's preferable if 00:00:00 is used.
What's the best practice for this, and what should I use?
1) Should the client convert times into UTC, and then save those to the server. And then when the client fetches times, convert it back into the user local time?
2) Should the client just push up whatever time it wants, and leave it for the server to decide what to do with it?
Here's what I'm doing with my apps:
Backend/server only deals with UTC. Always store times in UTC into the MySQL database (or whatever database you're using).
Push the conversion of time differences logic to the client. Most clients have a third party solution dealing with conversion of time (for iOS, check: https://github.com/yannickl/YLMoment ).
In mobile clients, I would still store the times in UTC into the local database. The only time I do any conversion is when the date is being displayed on the UI. This allows for users to travel into different timezones and the dates will be updated to reflect the local timezone.
I have a cron that runs a script in my rails app hourly looking for new transactions to run. Typically this only picks up new transactions set to start on the current day, until midnight UTC, when all the following day's transactions become due. My rails app is operating in Central Time, but Postgres is set to UTC. Since I'm using a scope with a where clause, and now() to compare the dates, transactions for the new day run in the early evening (in the US). Is there a downside to switching Postgres's timezone to Central Time? From what I can tell, it will record all timestamps in UTC regardless, but will run queries based on its timezone setting.
You should always use UTC inside the application, and only perform conversions to other timezones at the edge of the application where necessary - such as in controllers or views.
In your query, perform some date manipulation on now() to translate it to the timezone you need.
I receive from my server (MST timezone) and i convert it to GMT but there is an issue. Today 11 march 2012 the server changed it's time +1 hour because of daylight change. I query the server from Italy where the daylight did not occur yet (it will occur in 25 march 2012) so when i make the conversion the message i send from the client to the server its not at the right time because it returns minus one hour! For example
I send a message from the client from italy at 12:30 local time
the message is saved on the server at MST time.
After a second i retrieve the same message from the server and i make the conversion locally on the client.
The conversion shows me the that the time i have sent the message was 1 hour before.
That did not happened before the daylight change.
How can i solve this issue?
Any help appreciated.
You can solve this issue by not using local time in your network protocol. Exchange UTC times only between your client and server. Convert to local time for purposes of displaying data to the user.