I hope nobody asked this question here before,
I am creating a timestamp on the client side, mobile app (different countries)
I am getting a timestamp from the server (always the same country)
My goal is that both unix timestamps should have the same timezone (client & server). Is there a way in JS or jquery to transform both to one zone?
best
M
Related
I have a .NET web site that captures a C# DateTime value and stores it in database with UTC value. Upon showing that datetime value on web page, what I want is that date time UTC value to be converted to web user's local time zone properly. So web users in different time zones will see the displayed date time value with different date time results.
I have 2 following approaches. I do not know which is the best and correct one.
Approach 1: Let C# server side codes to convert the UTC DateTime value to local date time using .NET library method DateTime.ToLocalTime() and pass that converted value to client side to display without any further client side codes.
Approach 2: I do not do any time conversion using C# server side codes. Instead, I simply pass the UTC datetime value to client side and I will use some client side (javaScript or some JS library) codes to do the conversion before displaying it to web user.
Question 1: Approach 1 or Approach 2 is the best and correct one?
Question 2: The .NET library DateTime.ToLocalTime() method will convert a datetime value to local time of web user; web server's local time; OR web user's computer OS time?
Question 3: How can I test my web page with different time zones to see the best/correct approach working?
Thank you for your help.
I suggest that all date/times be stored in UTC on the server and that, in your case, you do the web client timezone conversion on the client side. I suggest the Moment library for client-side operations. If you use Moment, look at the guess() method for determining the client's current timezone.
By the way, you might want to determine the client's current timezone periodically in case 1) the user in on a mobile device and physically moves to another timezone or, 2) the user's session lasts long enough to transition from Daylight Savings Time (DST) to Standard Time (STD) or vice versa.
Now, I said "in you case" because, based on your question you don't seem to need to worry about calculating time intervals between 2 date/times. If you need to do that you also have to consider the complication of changes in a timezone from 3 sources:
Changing from STD to DST (and vice versa) that occurs twice a year in many timezones.
Changes to the UTC offset of a timezone that sometimes happens when a government implements a change.
Changes to the date/time when a location converts from STD to DST or vice versa.
Also, you might need to consider the complication of dealing with the potential for a local time corresponding to two UTC times! This can happen when a local time for a location falls within the 1 hour preceeding the date/time when that location converts from DST to STD. That 1 hour period is repeated when a 'fallback' from DST to STD time occurs and so you need to resolve which of 2 possible UTC times you want to store in your database.
If any of the above timezone complications might exist for you, consider storing a location along with the date/time since this context is required for timezone calculations. The location can be lat/lon which you would need to map to a timezone or you could keep it simple and store just the timezone. Lat/lon is sometimes more desirable since sometimes governments decide to move a location into a new timezone (but this is pretty rare).
I create project with php Laravel framework and VueJS and I want to get the difference between server time and client time to process some data time out by Javascript in the client browser.
How can i do that?
I need to change the format of one of the dates to be available to manage by other language functions and property.
how to sub (minus) Carbon::now() got from php api Date.Now() in JS.
I do that to get the difference between client clock and the server.
In order to "speak" in dates, the best practice is to work with timestamps.
The server can have its own timezone offset which is why it is best that it will expose any managed dates in UTC.
The client, on the other hand, will need to convert the UTC timestamp to its locale date, which can be done by adding its timezone offset.
Having said that - you will probably want to calculate the data timeout on the server, since the client can be bypassed, thus exposing a timed-out data to potential hackers.
Hope this helps :)
I'm new with javascript and I am using moment.js.
My code is const date = moment().
Let's supposed one of my website's user (A) is using a VPN, locating him to an area using a different timezone. The other user (B) is using the website in the same country but with no VPN.
Will the value of date be different for the two users, and will it's timezone be the same?
Thanks in advance!
Not necessarily, although it has nothing to do with the IP address/VPN usage.
The date, time and timezone that new Date() will give is entirely dependant on the host OS configuration. There's even no way you can guarantee that 2 machines on the same network have the same/different time or date.
In our application we are Saving the UTC DateTime in DataBase. Client (javascript) is sending the datetime in Local TimeZone and at controller level we are converting it to UTC time before saving the date in Database.
Both the client and servers are on different timezones.
we are fetching date from database in UTC Using Entity Framework with
DateTime.SpecifyKind(_CreatedDate, DateTimeKind.Utc);
So should we again convert the DateTime to local DateTime at controller or should we handle all the DateTime conversion logic at the client.
When sending DateTime instances to the server conversion conversion to UTC should happen as early as possible. In this case by the client and as your client is javascript you can use the method toUTCString. If you are using momentjs you can use utc.
When receiving DateTime instances from the server conversion conversion to local time should happen as late as possible. Make sure that persisted dates/retrieved dates are in UTC when you create them. Again, it is the client that should be converting them to local date time instance.
Finally send all datetime instances between client and server using ISO8601 format. Momentjs, javascript's date object, json.net all can do this. This ensures nothing is lost and no cultural specific bugs are introduced.
As to why it should be handled at the client is very simple, its easiest to do it there. Only the client truly knows its timezone, this is usually very difficult to "guess accurately" on the server side. The only reason not to do this is if you wanted to store a users timezone info with their profile but even this can get very tricky (what happens if the user travels or if they move location, etc).
As to how to persist you can use either a DateTime type or a DateTime with offset type (the true type names depend on the RDBMs you are using). Which one you choose should depend on if it is important to know the offset from utc at the moment it was saved. So far I have not had a need to do this but maybe it is important for you. It has no influence on the actual point in time as a DateTime should represent the UTC point in time and with offset should represent the local time with offset to get back to the UTC point in time.
Here's the way we do it in our projects. In my opinion, you should be using datetimeoffset in your database. This allows you to be able to identify what timezone the date was saved in. Then, when you send your date from your client to your server, just make sure it's sent in datetimeoffset.
When you send the datetimeoffset from the server to the client, you can do the conversion on the client side. I don't think anybody would argue that MomentJS Timezone is the best library for this. Look over it and give it a shot.
http://momentjs.com/timezone/
Elaborating on DateTimeOffset
DateTimeOffset is another datatype like datetime except datetimeoffset adds an hour offset to determine the timezone. For instance, let's say you're in Central Timezone and you want to save the time 08:00 am. Well, in Datetimeoffset, it would be something like 08:00:00:00 -04:00 declaring that the offset was -4 (central timezone). This makes it easy because you don't have to do any math in your head when reading it and you really don't have to do any conversions (let MomentJS do it for you). When you read it, you will always know that "Oh, it was 08:00 am for whomever saved the time, and it looks like they saved it in Central timezone."
Since it's quite relative when is the "Proper" time to convert.
The only absolute rule i think is valid is this one.
UTC time is the only Real meaningful data
Any other conversion to any timezone is just a "Display" for me
So follow the same rules as you would with the rest of your data.
Like converting a Boolean to a Checkbox on the view.Or sending that checkbox value as Boolean to the server.
And that's the soonest it Reaches or Leaves the UI.
I searched this on goolge and stackoverflow but couldn't find any satisfying answers.
I had some troubles with datetimes and timezones and i was wondering what the best way would be to transfer datetimes back and forth between server (c#) and client (javascript) ignoring the timezone.
I use JavaScriptSerializer on server and JSON.stringify on client.
Currently i convert the dates into ticks.
Any advice appreciated.
Actually time SHOULD be different because of timezone. Hours (and sometimes minutes if zone definition includes minutes) are changed as well as zone, when client deserializes datetime in a different timezone. If you want client to get same hours and minutes clear zone info before serialization.
DateTime.SpecifyKind(date, DateTimeKind.Unspecified);