CODEWITHSUNDEEP
javajavascriptdatetimestamp
youri
youri

Reputation: 3866

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

  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

=> 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

Upvotes: 0

Views: 1312

Answers (2)

Peter Lawrey
Peter Lawrey

Reputation: 533492

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

Upvotes: 2

thirtydot
thirtydot

Reputation: 228162

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.

Upvotes: 3

Related Questions