I write a notification based web app. I have to set notification times in the client side, send to the server, save to mysql database, continuously check for notifications, when the time is ready, send alert to the client. Simple as pie. Problem is, i'm pretty noob with timezones stuff. My server is in GMT-4, I am currently GMT+2, but in a few month i'll be in GMT +1 because of winter time. I can't get my head around the solution.
So far, i use moment.js on the server side and javascript built in Date object on the client side and i save times in unix timestamp.
My question in short: How to keep track on timezones and stuff, if i don't want any problem if i move my server from gmt-4 to lets say gmt-5 and don't want any problem with seasonal timesone change.
Thanks to spend time on my problem!
Best regards.
The issue of storing timestamps is simple: Store them in UTC.
As for displaying them in client again, Take the device (client) timezone and convert utc to device time zone.
Related
I have an app that can order an item, we have 3 timezone users (UTC+7, UTC+8, UTC+9)
every store is open at 07:00 until 17:00, I need to check if the user request an order but outside working hours, what I have done is sending order time from user app to back-end then I compare the time, but there is a bug, we still can change the time on user app within store's open time and they still can order, what is the best way to handle request from multiple timezone
Note: the back-end server is using Node.js
In frontend app you need to send the shop id and keep that configuration on the backend. You can normalize dates to be set in UTC which should make things easier.
After you send request you know what shop is sending it and in configuration you should get the working hours in UTC. Then you check actual time in UTC and you can decide whether making order is allowed or not.
It is important to store the dates with timezone offset using correct format (ISO 8601).
Another option is to send the dates using iso 8601 (with timezone offset) and on backend you need to normalize it to UTC and check whether requests are allowed or not.
I am using MomentJs to get the unix timestamp to manage a datetime message property.
Date: moment().valueOf()
the problem is that if someone uses a computer that has the machine's time a little ahead, that time will be recorded and a message that was sent before, will look like it was sent later.
At the moment I'm using a react application that is running on my network "localhost:300" and one of my computers has a different time from the other. So I have to prevent this time difference from being recorded by MomentJS
how can I configure MomentJS to NOT use the local machine's timestamp but from another centralized place?
I'm developing a web application (PHP server side ) in which users from all over the world can access.
Suppose now a user from New York (UTC - 4 ) login to my website (Server is located in Italy (UTC +2 )). When he is logged into it, the server will set a timestamp in that user SQL table with UTC +2.
Suppose now that this user want to get his last time access: he will get a wrong date (6 hours offset due to the different location of the server ).
How can I prevent this unacceptable behavior ? Should I store an UTC offset each time user logs in ?
It is highly recommended that you store all your timestamps for all your user in a single timezone, which by convention would be UTC.
It will make it much easier to manage the database table, for example sorting users by timestamp.
You can either change the timezone to UTC of your server, of the PHP module or locally in your code.
I am using kendo datepicker. I want user to pick a date. I will save it in the database.
here's the problem.
when user in india picks "1/1/2011". the value I get back from kendo datepicker is
LOG: investmentStartDate: Sat Jan 1 00:00:00 UTC+0530 2011
after I save it to the database, the date changed to "2010-12-31". I think that happens because of the timezhone, both my application server and database server are eastern time.
my users can come from anywhere, japan, china, india or london. is there a way i can convert this time to the actual date regardless which timezone they live in.
Give us a little more info about your server side. I had quite some experience and trouble with timezones and kendo the other day. I managed to overcome it, so maybe I can help.
The general best practice I followed and most people like is to keep your server data in UTC timezone format, and then add the timezone difference on the client side.
The way it works for me is I pull in a DateTime from my server which is in UTC via a REST service. I have an event that fires after the datasource reads the time from the server on the clientside, the event logic finds out the browsers timezone and adds the difference to the UTC time. The user can then pick the time which is shown in his timezone. When he clicks the save button, before sending the changed data to the server, it once again gets converted the UTC timezone and is being sent to the server in that format.
I've been asked to display the 'correct' time on our website which I frankly feel is rather pointless as 'correct' can be interpretted in such a variety of ways.
Our current method definately results in an inaccurate time as it uses a server control rendering JavaScript that runs onload using the datetime from the server as a parameter to create a clock object in JavaScript that finally renders on the page and then starts incrementing the clock. Between the server processing, network latency and client-side performance (there's plenty other stuff running onload) the clock ends up way off the actual server time and who knows compared to the client PC.
So to get the 'correct' time shown I could;
Use local PC time and pass new Date() to the JavaScript clock object. Pros: Should be as close to the PC clock as possible. Cons: Not sure how accurate the PC clock is let alone in which timezone.
Use web service for TCP request to NTP server to update clock on web page. Pros: If local PC also sync'd to NTP will be accurate and best possible match. Cons: Will have to handle all the timezone adjustments relative to our servers. If PC clock is out will still have mismatch.
Do I implement my own web service or use something like; Earth Tools or World Time Web Service (EDIT: link removed - now 404)
Here's a blog post from Jon Galloway on Atomic Clock Web Service which is pretty old and yet ranks high when I google and he doesn't reach a conclusion.
Hoepfully I can win the argument with management why syncing to our server clock (GMT) doesn't makes sense if your not in that timezone and why we even need to match a local PC.
Any angles on this I'm missing?
I needed to show the accurate time to clients in an auction web app. You can send the current server time with the page and have the javascript initialize right away without waiting for the rest of the page to load. So the, you only are dealing with network latency which in the worst case is not likely to be more than a couple of seconds.
After that, you're pretty darn close to accurate time. As long as your Javascript timer code is written properly, you're not going to far out of sync before the next page load. But I have seen a lot of bad JS clock code. (Hint: Date() good, setTimeout() bad.)
If you have an application that users are going to be sitting on for a long time, just refresh your time sync either by reloading the page or Ajax.
I wouldn't worry about time zones, just use UTC time so there is no confusion about what time things will happen.
First, be certain that your client is aware that Windows, Linux, and OSX all have built-in clocks that are almost always visible to the users (or made visible very easily). Also, be certain that your client is aware of physical clocks that are often located near any kiosks that might be setup to hide the built in clock from the operating system.
If you know that, and your client still wants a clock on your website, have your client define "correct" time, then implement the solution that matches their definition (both of your solutions seem like they would take care of the two most-likely definitions).
you can use geo targeting to know the physical location of a website visitor and in your database stored the (GMT - XX:XX) of the zone and then calculate the time based on the location of the request. that is going to save the long trip to any third party web service.
Another way you can implement it is using IP Geolocation. There are services that can tell you where your user is connecting from based on it's ip (usually including their timezone) and combining that information with your server's realtime clock you can show the user it's local time.
It's far from perfect, specially with corporate users that might seem to be connecting from somewhere they are not (I live in Argentina, but my work internet connection is trough my employeer that is an American company, so every website assumes I'm located in the US)
Handle time in UTC.
Have users tell you what zone they want to use.
If your users have persistent profiles, persist the choice.
Always display UTC and Local Time side by side and clearly labelled.
You can also display an arbitrary number of user specified zone clocks. Vista
does this and I remain surprised at how
handy it is.