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.
Related
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.
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/
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'm trying to implement a simple sync solution to propagate a few settings between various instances of my app and my server. Changes to these settings will be infrequent and only occur on the client(s). I would like something reasonably robust without going overboard.
My strategy is to track un-synced changes on the device, and when syncing, post these to the server. The server should be able to reject a change that occurred after the previous known sync for that setting. To accomplish this, the app stores an 'Updated' date for each setting, and the server compares this to a similar field it stores for the same setting on its side. If the client's date is prior to the latest setting sync the server knows about (from a different device), the sync for that setting is rejected.
The final (hopefully) piece is to account for differences between the client and server clocks.
My initial thought is to send (alongside the updated setting), the client's current local datetime. On receipt, the server will compare the client's time to its own and know how to adjust the 'updated' timestamp on the client's setting. This sounds reasonable to me in principle, but how can I address the following two issues?
What if the client device's clock is changed after the setting is updated by before attempting to sync it?
Who knows how long the sync request will take to reach the server? So by the time it is received, the 'System clock' that the client provided is actually seconds or minutes out.
You should do everything in terms of UTC to avoid time zone issues. That doesn't get round the issue of the users clock just being set incorrectly so you may want to check-in to the server when data is updated to verify what the actual time is. There will be some conditions that are hard to deal with if you have no net connection. Sometimes the best you can do is to detect them and tell the user about the risk.
It is said that the web servers' clocks must be identical for the Expires and Cache-Control headers to work? Why is that? Can't they be off by 1 second or a few minutes?
If the cache is supposed to be good for 1 year, then won't a time difference of a few minutes or even a few hours not matter on one or some of the web servers?
In the documentation it is said that:
note that in order for this [caching] to
work, all your application servers
must return the same timestamps. This
means that they must have their clocks
synchronized. If one of them drifts
out of sync, you‘ll see different
timestamps at random and the cache
won‘t work. In that case the browser
will request the same assets over and
over again even thought they didn‘t
change. You can use something like
Live HTTP Headers for Firefox to
verify that the cache is indeed
working.
If you run ntpd on all your hosts (and you do, don't you?) they'll be more than close enough. It has less to do with the headers than with the caching controllers generating the ?1232285206 at the end of the URLs. That's just a Unix epoch time (seconds since 00:00:00 Jan 1 1970), so being within a few seconds should do just fine for content that is okay to cache. ntpd typically keeps a quarter-second or less tolerance. (In a series of ntpdate tests against multiple time servers, my computer was never more than .15 seconds off.)
Note that this is Rails specific and only in the case where you have more than one web server serving the data.
Given that the cache stores the data using a timestamp, if the servers differ on what the timestamp is, the cache will always be invalidated on one of them (the one with the 'older' timestamp) as it will always think the file has been recently updated and thus think the request as a cache miss.