Отклонение метки времени Java от Javascript для старых дат (3600сек) - PullRequest
0 голосов
/ 21 марта 2012

При преобразовании строкового представления даты в числовые значения я получаю другой результат в Java / Groovy / PHP по сравнению с Javascript.Для некоторых дат до 1970 года метка времени JS ровно за 3600 секунд до метки времени Java.Я мог бы воспроизвести его для 1 октября, но для 1 января это нормально.

Мой тестовый пример (в Groovy, с использованием обычного Java API специально):

def sdf = new SimpleDateFormat("dd/MM/yyyy")
["01/10/1956", "01/01/1956", "01/10/1978"].each {
    def d = sdf.parse(it)
    println "${it} -> ${d.time}"
}

и в JS (Я просто запускаю его из консоли Chrome - здесь "9" - октябрь):

new Date(1956, 9, 1, 0, 0, 0).getTime()

Несколько примеров:

* Groovy

  1. 01/10/ 1956 -> -418179600000
  2. 01/01/1956 -> -441853200000
  3. 01/10/1978 -> 276040800000

* Javascript

  1. 1956,9,1,0,0,0 -> -418183200000
  2. 1956,0,1,0,0,0 -> -441853200000
  3. 1978,9, 1,0,0,0 -> 276040800000

=> Обратите внимание, что 01/10/1956 не преобразуется одинаково, получая разницу в 3600 секунд.

Дневной светэкономия времени или часового пояса была бы идеальным виновником, но я не понимаю, почему две вселенные разошлись в какой-то момент в прошлом.

Любой намек приветствуется!

Спасибо

РЕДАКТИРОВАТЬ больше образцов

* Java / Groovy

01/01/1974 -> 126226800000
01/10/1974 -> 149814000000
01/01/1976 -> 189298800000
01/10/1976 -> 212972400000
01/01/1978 -> 252457200000
01/10/1978 -> 276040800000    

* JS

new Date(1974, 0, 1, 0, 0, 0).getTime()    126226800000
new Date(1974, 9, 1, 0, 0, 0).getTime()    149814000000
new Date(1976, 0, 1, 0, 0, 0).getTime()    189298800000
new Date(1976, 9, 1, 0, 0, 0).getTime()    212972400000
new Date(1978, 0, 1, 0, 0, 0).getTime()    252457200000
new Date(1978, 9, 1, 0, 0, 0).getTime()    276040800000

Около 1967 ~ 1971

01/01/1967 -> -94698000000
01/04/1967 -> -86922000000
01/10/1967 -> -71110800000    
01/01/1968 -> -63162000000
01/04/1968 -> -55299600000
01/10/1968 -> -39488400000
01/01/1971 -> 31532400000
01/10/1971 -> 55119600000

new Date(1967, 0, 1, 0, 0, 0).getTime()   -94698000000
new Date(1967, 3, 1, 0, 0, 0).getTime()   -86925600000
new Date(1967, 9, 1, 0, 0, 0).getTime()   -71114400000
new Date(1968, 0, 1, 0, 0, 0).getTime()   -63162000000
new Date(1968, 3, 1, 0, 0, 0).getTime()   -55303200000
new Date(1968, 9, 1, 0, 0, 0).getTime()   -39492000000
new Date(1971, 0, 1, 0, 0, 0).getTime()   31532400000   
new Date(1971, 9, 1, 0, 0, 0).getTime()   55119600000   

Ответы [ 2 ]

3 голосов
/ 21 марта 2012

Ваш профиль говорит, что вы из Бельгии.

В 1976 году для Брюсселя нет перехода на летнее время:

http://www.timeanddate.com/worldclock/clockchange.html?n=48&year=1976

Но с 1977 года:

http://www.timeanddate.com/worldclock/clockchange.html?n=48&year=1977

Вероятно, об этом знает Java, а JavaScript нет.

2 голосов
/ 21 марта 2012

Информация о часовых поясах сложна, и вы будете удивлены, как часто а) они меняются, б) неточны.

Я бы попробовал это и в Java / Groovy.

new Date(1956, 9, 1, 0, 0, 0).getTime()

Классный сайт о часовых поясах.http://www.bbc.co.uk/news/world-12849630

Например, эпоха 1970/01/01 00:00 UTC.Не Европа / Лондон, потому что, хотя была зима, Великобритания была в BST (британское летнее время). Это происходит только с февраля 1968 года по ноябрь 1971 года.: P http://www.timeanddate.com/time/uk/time-zone-background.html

Чем больше вы узнаете о времени и датечем больше вы понимаете, все это скорее adhoc.Даже UTC не является аббревиатурой как таковой, это означает «Всемирное координированное время» на английском языке и «Temps Universel Coordonné» на французском языке, и потому что они не могли договориться о том, какой аббревиатурой должен быть компромисс, с которым UTC является ни тем, ни другим.http://en.wikipedia.org/wiki/Coordinated_Universal_Time

...