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.
Related
This might be a very specific problem or just ignorance from my side, but I don't seem to figure it out.
Within our organization, we have a FreeRadius Accounting system logging sessions from Wi-Fi usage. Our team is responsible for the data analysis of this accounting data.
Recently, we had to dump the Radius Accounting Database and made a freeze frame of it. While doing so we found a weird behavior.
Running the same query before and after the dump (a query that retrieves the total amount of sessions for a single day) gave a different amount. Around a difference of 5-10%.
Looking a bit deeper we discovered that several updates were being issued that altered the start time of sessions after they had been first registered in the accounting database.
We then found that previous data we collected had disparity after weeks or months even (with the discrepancy being around 2-10%).
TLDR:
Does FreeRadius adjust the start times of sessions based on some maintenance? Are WiFi controllers allowed to do this? Is it a bug?
Overal we just want to understand the rationale so we can justify the data and adjust our processing correctly, as currently, we cannot trust the values we collect daily or even weekly on these stats!
Any help or insight would be great!!!
FreeRADIUS only updates the database as a result of data in an incoming RADIUS packet, using the SQL queries in the local configuration. The only real way to understand this is to look at your SQL queries, and incoming requests (via radiusd -X) and see what is making changes to the data. It is possible that the NAS is broken and sending invalid or changing data, or possibly re-using session IDs which overwrite existing records.
It is also possible to configure FreeRADIUS to create a "fake" accounting start entry in the database in post-auth, which will then be updated when the real Start packet arrives. If you are doing this then you should check the values that are being written, and also if the session never starts up (or the Start is lost) then bad things might happen.
But in all circumstances the only solution you really have is to look at the debug output and see what is happening and why data is being written in the way that it is. There is nothing in FreeRADIUS that randomly updates the database without being sent that data from the NAS.
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.
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'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.
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.