This question already has answers here:
Are Javascript date/time functions dependent on the client machine?
(5 answers)
Closed 8 years ago.
Consider this line of code:
var currentTime = new Date();
Did it look at my IP address? Did it talk to my local machine?
How javascript determines what current time in my time zone is?
Since javascript is a client-side language, the Date() method implemented in the browser is querying the client machine for the current time. If you want a date you can trust, query a server for a timestamp and use that in your calculations.
Relevant answer
The JavaScript parser asks the browser, which asks the computer, which looks it up internally. Most languages have a feature for date/time.
It uses the timezone that's configured in the OS the browser is running on.
The JavaScript Date() function returns number of milliseconds from 1 January, 1970 UTC.
If no arguments are provided to the constructor (new Date()), the constructor creates a Date object for the current time according to your system settings
This question already has answers here:
The best way to synchronize client-side javascript clock with server date
(8 answers)
Closed 9 years ago.
I have a scenario in which I have to show ticking time to the user of a post. The post will come with is original DateTime string from server then the values will be calculated on client to find the difference of the time elapsed. The issue is that client time can't be relied upon. So the decision is that to retrieve the server current time and find the difference between the client and server and add that difference to the client date and then add the difference to the client time before calcuating the time elapsed.. however I don't know how to find the difference in javascript and add it client date variable.. Can someone talk on this scenario and codify it.. I am not sure whether I am doing right or is there alternative to it?
So I come up with the solution now.. as I mentioned to use the variable to store the server current time and update that variable after each specific interval in setinterval. This variable is going to work as our client side clock and compare the post time with it.. the issue with client clock is that it can't be trusted..
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Javascript/PHP and timezones
It is possible to get the Olson timezone id from javascript on the client's machine e.g. (America/New York). I know that PHP can do this via the timezone object, something like this. $timezone->getLocation(); Does similar functionality exist for JS?
I know that you can grab the timezone offset of the client as followed:
var curdate = new Date();
var offset = curdate.getTimeZoneOffset();
But I need more granular information provided by the Olson Id. Thank you for your help.
You can't directly access timezone in JavaScript. You can, however, measure offsets reported at several different specific dates to deduce what exactly time zone is in use by comparing regular and daylight savings times to database of zones. There's a jsTimezoneDetect library that can do most of this work for you.
This question already has answers here:
How to initialize a JavaScript Date to a particular time zone
(20 answers)
Closed 6 years ago.
I have a web application that has a dynamic javascript calendar, which allows users to set events for a given data and time. I need to push notifications to the users, so I need to convert the date time and timezone they entered, into Eastern Standard Time, so that my notifications are sent out at the correct time.
I would like to do this in javascript, so that when the data time value gets to the php, it's in the right format, before being added to the database.
So to summarize, I need to convert a javascript datatime and timezone, which I get by capturing the users datatime, as a full UTC date, to my servers timezone, which is EST - New York.
Any help or direction on this matter, would be greatly appreciated.
Thanks :)
Pl check this script
function convertToServerTimeZone(){
//EST
offset = -5.0
clientDate = new Date();
utc = clientDate.getTime() + (clientDate.getTimezoneOffset() * 60000);
serverDate = new Date(utc + (3600000*offset));
alert (serverDate.toLocaleString());
}
I would draw the EST timezone offset into the page while you're rendering it (via PHP) and then grab the UTC time on the client and offset it by the amount you've drawn in. Otherwise, if your server ever moves timezones your page will suddenly be reporting the wrong time.
I just did this recently though, and found that the simplest way to handle this is to actually use mySQL (I'm assuming that's your DB), and just let IT convert the timezone for you while you're entering the date stamp. Unless you're worried this is too tasking and you're trying to absolutely reduce the work your db is doing, I'd go that route, rather than muck about trying to do manual TZ conversions in JS.
Let's say I have a date that I can represent in a culture-invariant format (ISO 8601).
I'll pick July 6, 2009, 3:54 pm UTC time in Paris, a.k.a. 5:54 pm local time in Paris observing daylight savings.
2009-07-06T15:54:12.000+02:00
OK... is there any hidden gem of markup that will tell the browser to convert that string into a localized version of it?
The closest solution is using Javascript's Date.prototype.toLocaleString(). It certainly does a good job, but it can be slow to iterate over a lot of dates, and it relies on Javascript.
Is there any HTML, CSS, XSLT, or otherwise semantic markup that a browser will recognize and automatically render the correct localized string?
Edit:
The method I am currently using is replacing the text of an HTML element with a localized string:
Starting with:
<span class="date">2009/07/06 15:54:12 GMT</span>
Using Javascript (with jQuery):
var dates = $("span.date", context);
// use for loop instead of .each() for speed
for(var i=0,len=dates.length; i < len; i++) {
// parse the date
var d = new Date(dates.eq(i).text());
// set the text to the localized string
dates.eq(i).text(d.toLocaleString());
}
From a practical point of view, it makes the text "flash" to the new value when the Javascript runs, and I don't like it.
From a principles point of view, I don't get why we need to do this - the browser should be able to localize standard things like currency, dates, numbers, as long as we mark it up as such.
A follow up question: Why do browsers/the Web not have such a simple feature - take a standard data item, and format it according to the client's settings?
I use toLocaleString() on my site, and I've never had a problem with the speed of it. How are you getting the server date into the Date object? Parsing?
I add a comment node right before I display the date as the server sees it. Inside the comment node is the date/time of that post as the number of milliseconds since epoch. In Rails, for example:
<!--<%= post.created_at.to_i * 1000 %>-->
If they have JS enabled, I use jQuery to grab those nodes, get the value of the comment, then:
var date = new Date();
date.setTime(msFromEpoch);
// output date.toLocaleString()
If they don't have JS enabled, they can feel free to do the conversion in their head.
If you're trying to parse the ISO time, that may be the cause of your slowness. Also, how many dates are we talking?
Unfortunately, there is not.
HTML & CSS are strictly used for presentation, as such, there is no "smarts" built in to change the way things are displayed.
Your best bet would be to use a server side language (like .NET, Python, etc.) to emit the dates into the HTML in the format you want them shown to your user.
It is not possible to do this with HTML, it has no smart tags that can make any kind of decisions like this. It is strictly presentational. I do wonder, though, if HTML5 perhaps has a tag for something like this...
Anyways, the way I see it, you have 3 options:
Stick to the Javascript way. There's questions with more details on it on this website, such as How do I display a date/time in the user’s locale format and time offset? and How can I determine a web user’s time zone?
Try to use geolocation. That is, your server side script fires off a request to one of the many geolocator services out there on the user's first page visit to try and guess where the user is. The downside of this is that it will be wrong about 10% of the time, so it's not that much better than the market share Javascript is going to get you.... (all in all, then, not a very good method...)
Ask the user! You will see that most websites that want to display a tailored experience for you will ask you this sort of thing because it's just not possible to know. As a neat fallback, you could wrap the question around <noscript> tags so you only ask those with Javascript disabled while offering the Javascript experience to those that have it.
Dojo has some pretty good localizations for dates and currencies. Using this method also allows you to pick different formats (e.g.: short date vs long date) and force locales.
The language and the user's locale should be sent on the HTTP header. You can use those to create the correct date format server-side to be displayed to the user. However, this is often undesirable because many users completely ignore their locale settings in their OS and/or browser. So, you may be feeding USA style timestamps to New Zealanders.
I liked the trick posted in the comment above, but it sounds like a QA headache, since you could be dealing with a large number of clients that implement timestamps in very different ways.
The most effective solution I have seen, is to simple provide a panel to allow your users to choose what time format they like. Some users even ****gasp**** like ISO formats. Then you do the time format conversion server side. If your application language does not have good locale to timezone formatting mapping, check your database. Many databases provide locale-based customized timezone formatting as well.
Because this anwser still popups in google I share that this is now possible to do by using a readonly datetime-local input (see below) and you can then style the input the way you want:
<input type="datetime-local" value="2018-06-12T19:30" readonly />
For more information see: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local