Timestamp deviation Java vs Javascript for old dates (3600secs)
When converting string date representation to numeric values, I obtain a different result in Java/Groovy/PHP vs in Javascript. For some dates before 1970, the JS timestamp is exactly 3600 secs before the Java timestamp. I could reproduce it for Oct 1st, but for Jan 1st it's ok.
My test case (in groovy, using the usual Java API on purpose):
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}"
}
and in JS (I simply run it from the Chrome console - "9" is October here):
new Date(1956, 9, 1, 0, 0, 0).getTime()
A few samples:
*Groovy
*Javascript
=> Notice how 01/10/1956 is not converted the same way, yielding a 3600 seconds difference.
A daylight saving time or a timezone would be the perfect culprit but I don't see why the two universe diverged at some point in the past.
Any hint welcome!
Thank you
EDIT more samples
*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
Around 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
Your profile says you're from Belgium.
There's no daylight saving time in 1976 for Brussels:
http://www.timeanddate.com/worldclock/clockchange.html?n=48&year=1976
But there is from 1977 onwards:
http://www.timeanddate.com/worldclock/clockchange.html?n=48&year=1977
Java is probably aware of this, whereas JavaScript is not.
The information about Timezones is complex and you would be surprised how often a) they change, b) they are inaccurate.
I would try this in Java/Groovy as well.
new Date(1956, 9, 1, 0, 0, 0).getTime()
A cool website on timezones. http://www.bbc.co.uk/news/world-12849630
For example, the epoch is 1970/01/01 00:00 UTC. Not Europe/London because even though it was winter, the UK was in BST (British Summer Time) This only happen from Feb 1968 to Nov 1971. :P http://www.timeanddate.com/time/uk/time-zone-background.html
The more you learn about time and date the more you realise its all rather adhoc. Even UTC is not an acronym as such, it means "Coordinated Universal Time" in English and "Temps Universel Coordonné" in French, and because they couldn't agree on what the acronym should be the compromise was UTC with is neither. http://en.wikipedia.org/wiki/Coordinated_Universal_Time
链接地址: http://www.djcxy.com/p/3106.html上一篇: UTC日期/时间字符串到时区