So Azure stores datetimes in UTC. What is the best way to handle it if my system need to have timestamps in, say, US Eastern Time? Do I store them in utc, but handle just displaying timestamps by formatting them? Do I format/offset timestamps before storing them in the database? What is the best practice for solving this issue?
I always advocate for storing in UTC time as it is the standard time in which you can calculate any other times zone off of. This means if you have a service in which any one can connect to from any location, it is easier to either detect the timezone the user in currently in based on their system, or have them save the timezone they would prefer to see the time set in from your application.
this thread had a very large discussion which talks about it at length, which you might be interested in reading to help make your decision. If you decide to store UTC and convert the time, here is a post explaining How to convert from UTC to Local Time in C#
Storing time in any persistent store (cache, db, queues, etc.) - always use UTC.
Time in User Interface - get UTC from your APIs (REST) and show it in the local system time (based on users' system).
Additionally, application can have an option or user settings to make timezone configurable.
Remember if you have multiple servers in a distributed environment, it is must to synchronize the clocks in all the servers.
Thanks.
Related
Newer developer here. I'm creating a Nodejs application with MongoDB. When do you write user inputs to the database? Is it immediately when they want to perform a CRUD action? Or do you wait until they end their session to update their changes (showing them a "fake" updated view during the meantime)? I would think writing to the database every time would be less than ideal, but I also wouldn't want to make the user think their changes were saved to the database, and then some error occurs where it didn't actually happen. How's this handled in the real world?
The user inputs should be written to the database as soon as the user wants to perform the CRUD operations.
If they are not, and you wait for the user to terminate their session, there may be other parts of the application that try and change the data that was supposed to be updated. Or you may want to take certain action in your application based on the current user data from the database, but your database reflects older data, and your application may behave incorrectly.
One may argue that you can maintain the current state of your application, but in case of backend code, the database should always be your single source of thruth.
This is what's known in the "real world" (as you referred to) as a design decision. It's not something for which there's anything even remotely resembling a rule-of-thumb or a hard-and-fast rule.
Instead, it's important to consider all possible factors relating to this design prior to committing to it:
User expectations - will the users of this application expect that their input is stored immediately? When they click the "Save" button? Do they expect their input to be destroyed?
Data retention - are there requirements to retain user input prior to its formal submission? (This is useful in applications for which
Infrastructure - can the underlying infrastructure handle the increased workload? When this application is scaled, will the infrastructure demands exceed capacity?
Cost/benefit - will the addition of this feature trigger development/testing times that exceed acceptable levels for the benefit the feature provides?
These are just some of the considerations you might have. I'm sure with additional time most people could come up with at least ten more.
I want to implement a system to track the how much has the user viewed a video. I am working on react, nodejs and mysql. I am able to record the amount of time of each session (a session being from (in milliseconds) and to (in milliseconds) when the video was played by the user).
I am struggling to find the best condition where i can confidently say that the user has completely viewed the video.
Is there any standard way to determine if a user has viewed the video completely? or a better way to track the progress?
Companies like the ones you mentioned usually use a third party ( such as mux or similar) to provide this service.
The way it works there, is the player software running in the browser is modified with a plugin to send state informant on an interval to a collection server, which aggregates this data and produces reports.
There is currently no standard format for the reported data, everyone does it differently.
I'm working on an application to connect to the Google Adsense API. As I'm based in the UK, my reports on the Google Adsense web login are all set to UK local time. However, the API data all seems to be solely in Pacific Time, AKA Google Standard Time :-)
This isn't necessarily a huge issue, as it doesn't affect actual earnings. But it does make it harder to track things like CPC and CTR on a daily basis. It would be easier if I could drill down into the data to hourly level, as then I could easily reallocate out-of-zone hours to the adjacent day. But that doesn't seem to be an option either, unless I'm missing something.
I've searched the documentation, but can't seem to find any means of controlling the timezone of API data. Is there any way to get the APi to deliver the data in a local timezone, or do I just have to put up with getting my reports in Pacific time?
As a developer you can't define a time zone to use, but as a publisher you can change your local time zone in the AdSense web interface. After that, you can use useTimezoneReporting when requesting a report.
Read the full explanation and "Things to watch out for" in:
https://developers.google.com/adsense/management/timezone
Situated in the UK, I request a saved report from AdSense API and with "yesterdays" data.
When triggered after midnight our time it pulls data from the day before yesterday...
I didn't know the API was functioning on PST time and just believed it would follow the local timezone set on our account.
Even though the documentation in the comment above mentions reports will be done in "local time" when set in your account, the API will still operate calls based on its own timezone (PST). +8 hours GMT.
So if you need to get "yesterdays" report, be sure to set the date on your call or adjust your schedule to match the PST time zone.
I have developed a windows application.I just want to set a trial period for 30days. After that the user should get the message about Trial period has been completed and make the buttons to be inactive state. Suggest me some links.
This is not something which can be done with a single thought. It depends on various factors related to your application. Is your application has access to registry or not? Is it installed with administrator privileges or not.
I can give you some idea on how do it with basic privileges.
Create an encrypted key which takes current system date and some other parameter which you can take as you wish and store this key in a file in the application folder or wherever you can.
Every time user starts the application get the key and decrypt it and check whether the date stored minus today is more than your trial period than based on that you need to do whatever action you can such as disabling buttons etc.
I'm sure there are so many other methods followed by others and everybody has their own criteria and constraints in this implementation.
Some questions you really need to ask yourself are:
How important is what you are trying to protect?
How much are you willing to pay (in time, money and effort) to
implement this behavior?
What are the chances people are going to try and bypass your
implementations?
Is the cost (in time, money and effort) going to be more than the
potential lose in income from people bypassing the trial period?
There is another question on SO with similar requirement, go through those answers as well.
As many APIs provides access remotely to their data through the user/password combination.
I was wondering which was the best way to store those value, highly secure way (even if 100% is impossible), in order to connect them directly without asking every time for those.
I recommend one of three approaches:
Avoid storing the password at all by using authentication tokens. In this model, the user logs in one time, and the server generates a unique, large, sparse token that the client can store and use as its login "password." The server only accepts this token from one client at a time, so if two clients try to use it simultaneously, the token is invalidated. The token is also generally invalidated after a period of time (1 week, 2 weeks, a year, whatever is appropriate). When the token is invalidated, the user must log in again by hand and the process is repeated. This is basically the approach of Gmail and similar web site logins.
If you must store the password, I recommend relying on the OS to manage it for you. Windows and Mac both have good secure storage systems (DPAPI and Keychain respectively). Linux doesn't have a good always-available solution, though, so it depends on your market. The advantage of using the OS is that the OS can provide protections you can't easily provide yourself, and the user can centrally manage the overall protection of the OS storage (using smartcards, etc.) to a level you are unlikely to reproduce. The OS secure stores are also typically quite convenient for the user.
If neither of these are options, then store an encrypted file with a master password that the user must enter every time they launch your app. This is how Firefox works (or at least it did last time I looked, which has been a while). This is reasonably secure, but much less convenient for the user (and low convenience often means low adoption by the users, or poor use through simpler passwords, etc). I would investigate the Firefox code as an example of how to implement this.
KeePass provides even an API to use for developers.
The best way would be to rely on someone else to store them and to trust that party instead. But if you must have control I'd suggest reading a good book on secure systems and then thinking again. There are many many variables to consider and most of the time you just mitigate the risk vs cost.