JavaScript читаемая дата / время из времени PHP ()
В этой теме уже много ответов, но тот, который лучше всего работал (и простейший - одна строка!) для меня, был модификацией комментария Нила Э. Пирсона от 21 апреля 2013 года:
< blockquote>Если вы застряли в своей кнопке отправки #submit, вы можете обойти ее, украв другой метод экземпляра экземпляра формы ().
Мое изменение в его методе, и что сработало для меня:
document.createElement('form').submit.call(document.getElementById(frmProduct));
3 ответа
Используйте для этого объект Date :
new Date(<?php echo time(); ?>*1000)
Вам нужно умножить временную метку Unix на 1000, потому что Date ожидает, что отметка времени будет в миллисекундах.
А для форматирования даты вы можете использовать этот метод Date.format ( Date не имеет встроенного).
Вместо числовой метки времени unix вы также можете отправить текстовое представление даты, которое понимает Date.parse () .
Может быть, это просто мой вклад в глобальное потепление, но я думаю, что есть преимущества в использовании формата, который удобнее читать и содержит информацию о часовом поясе.
например.
<?php
// I have "decided" America/Los_Angeles fits most of my audience
date_default_timezone_set('America/Los_Angeles');
$now = time();
$yesterday = strtotime('yesterday', $now);
// March 27, 1976 08:00:00 tz:America/Los_Angeles
$someotherdate = mktime(8, 0, 0, 3, 27, 1976)
?><html>
<head><title>...</title>
<script type="text/javascript" src="jquery.min.js"></script>
<script type="text/javascript">
function foo() {
$('.datetime').each( function() {
var t = $(this).text();
t = new Date(Date.parse(t)).toLocaleString();
$(this).text(t);
});
}
</script>
</head>
<body>
<div><span class="datetime"><?php echo date(DateTime::RSS, $now); ?></span></div>
<div><span class="datetime"><?php echo date(DateTime::RSS, $yesterday); ?></span></div>
<div><span class="datetime"><?php echo date(DateTime::RSS, $someotherdate); ?></span></div>
<button onclick="foo()">to local time</button>
</body>
</html>
Это напечатает
Sat, 17 Apr 2010 04:40:15 -0700
Fri, 16 Apr 2010 00:00:00 -0700
Sat, 27 Mar 1976 08:00:00 -0800
в моем браузере и (поскольку мой местный часовой пояс - Европа / Берлин, CET, UTC + 1/2) после нажатия кнопки по местному времени
Samstag, 17. April 2010 13:40:15
Freitag, 16. April 2010 09:00:00
Samstag, 27. März 1976 17:00:00
Вы должны быть очень осторожны, делая это. Когда вы берете значение времени на стороне сервера, которое является традиционным «количеством секунд (или миллисекунд) с момента границы эпохи», а затем превращаете его в своего рода объект «Дата», то перевод происходит в часовой пояс, соответствующий языковой стандарт контекста.
Проблема возникает, когда у вас есть сервер, расположенный в Чикаго, и кто-то на Гавайях использует ваш сайт, скажем, после вечеринки - одно из тех «луау», без сомнения, с жареным поросенком и танцами в траве. девочки, редкий вечер под теплым тропическим небом, экзотические цветы, благоухающие океанским бризом - а теперь уже поздно. Боже мой, уже почти полночь! Что подумает мама, когда я напишу ей о вечеринке?
Наша тусовщик садится в 23:30, чтобы воспользоваться вашим сайтом. Теперь, конечно, находясь значительно восточнее Гавайев, ваш сервер думает, что сейчас 5:30 утра, и эта дата на один день позже той даты, которую наш тусовщик запишет в своей записке для мамы. Таким образом, ваш сервер записывает свою временную стоимость на веб-страницу, как описано в ответах здесь, и - правильно - местное время Гавайев отображается на странице в номере нашего тусовщика.
Проблема заключается в следующем: если это местное время возвращается в ваше приложение из некоторого поля формы, и ваше приложение рассматривает его как местное время в Чикаго , тогда ваш сайт будет получить вчерашнюю дату.В зависимости от вашего приложения, подходит оно или нет - суть в том, что вы должны отслеживать , где дата (выраженная в обычном календаре) происходит от vis-a-vis, где дата - использовал .
У вас, конечно, может быть обратная проблема. То есть, если ваш сервер всегда отображает даты в своем местном часовом поясе, то пользователи в любой точке мира будут видеть запутанные (явно неправильные) значения даты и времени, поэтому интерфейс должен четко понимать, что означают эти значения. Проблемы становятся важными, когда ваш сайт предоставляет услуги, связанные с расписанием. Если можно запланировать операции, важно, чтобы интерфейс поддерживал все на уровне, чтобы «30 апреля в 22:00» означало либо дату и время на сервере , либо дату и время в локали. из которых был составлен график. Что бы это ни было, вы должны быть осторожны, чтобы сохранить последовательность.