React-native: new Date() bug

[Gigasz]

Is this a bug report?

Yes

Have you read the Contributing Guidelines?

No

Environment

1. react-native -v:
   react-native-cli: 2.0.1
   react-native: 0.46.4

2. node -v: v7.10.0

3. npm -v: 4.2.0
4. yarn --version:

Then, specify:

• Target Platform: iOS 11.0

• Development Operating System: macOS Sierra

• Build tools: xCode9 beta

Steps to Reproduce

Not sure if it's a react-native issue or iOS, but i'm setting a new Date('string') -the string comes from the server- and it converts to a Date on iOS emulator, however when I run on device it becomes an invalid date (as I console logged on xCode).

here the logs:

the log scheme: console.log('string identifier', 'new Date(string)', date string from server);

log commands:
console.log('dtini', dataInicio, this.props.programacaoLazer[i].data_inicio);
console.log('dtfim', dataFim, this.props.programacaoLazer[i].data_fim);
console.log('dtselec', this.state.dataSelecionada);
log on emulator:
dtini Tue Sep 05 2017 10:40:00 GMT-0300 (-03) 2017-09-05 10:40:00
dtfim Tue Sep 26 2017 13:18:00 GMT-0300 (-03) 2017-09-26 13:18:00
dtselec Tue Sep 05 2017 15:29:06 GMT-0300 (-03)

log on Xcode running on device:
2017-09-05 15:21:50.326 [info][tid:com.facebook.react.JavaScript] 'dtini', Invalid Date, '2017-09-05 10:40:00'
2017-09-05 15:21:50.326 [info][tid:com.facebook.react.JavaScript] 'dtfim', Invalid Date, '2017-09-26 13:18:00'
2017-09-05 15:21:50.327 [info][tid:com.facebook.react.JavaScript] 'dtselec', Tue Sep 05 2017 15:18:37 GMT-0300 (-03)

[ide]

Are you using the Chrome debugger? (Make sure you aren't using it for Date-related operations, V8 is different from JSC.)

[Gigasz]

yes i'm using chrome debugger on emulator.

i have fixed it by declaring the new Date as:

const dataInicio = new Date(
parseInt(atividade.data_inicio.slice(0,4)),
parseInt(atividade.data_inicio.slice(5,7)) - 1,
parseInt(atividade.data_inicio.slice(8,10)),
parseInt(atividade.data_inicio.slice(11,13)),
parseInt(atividade.data_inicio.slice(14,16)),
0,
0
);

However it`s funny that it works on emulator but not on device

[ide]

Can you try disabling the Chrome debugger?

[Resmedia]

For me helped this:
moment( date & time , "YYYY-MM-DD hh:mm a").format("YYYY-MM-DDTHH:mm:ss")
You can try to see it in Safari -> development->agent->IOS device
On IOS work good!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. If you think this issue should definitely remain open, please let us know why. Thank you for your contributions.

[nezaidu]

Same. Trying
new Date('2017-11-7, 6:37 pm')
with debugger off results in
Invalid Date
with debugger on result is:
Tue Nov 07 2017 18:37:00 GMT+0200 (EET)

[yalopov]

That's because react-native run javascript code using JavaScriptCore engine and it behaves like @Gigasz said, if anyone want to test code same way it would run in a real device, can install and use rhino

[SahRckr]

We've faced the same problem.
For some reason JavaScriptCore doesn't take "YYYY-MM-DD HH:MM:SS" format as a constructor param, (it does recognise "YYYY-MM-DD", and another format mentioned below)
Using moment.js might be an overkill, I wrote a tiny function that addresses this issue:

const jsCoreDateCreator = (dateString) => { 
  // dateString *HAS* to be in this format "YYYY-MM-DD HH:MM:SS"  
  let dateParam = dateString.split(/[\s-:]/)  
  dateParam[1] = (parseInt(dateParam[1], 10) - 1).toString()  
  return new Date(...dateParam)  
}

[connorpaulstauffer]

I ended up with a slight modification of @SahRckr's method to handle UTC dates.

This handles the format 2018-07-18 15:27:55 UTC. Note that it will break for anything non-UTC.

const parseUTCDate = dateString => {
  const dateParams = dateString.replace(/ UTC/, '').split(/[\s-:]/)
  dateParams[1] = (parseInt(dateParams[1], 10) - 1).toString()

  return new Date(Date.UTC(...dateParams))
}

[jbbae]

@connorpaulstauffer Thanks a ton! This immediately solved my problem!

[yoshikischmitz]

If your dates are in UTC an alternative is to remove the UTC component and replace the space after the YY-MM-DD with a T:

new Date(dateString.replace(' UTC', '').replace(' ', 'T'))

This works because JSCore correctly parses dates in the ISO 8601 format.

[Udbhav12]

I am facing another weird problem with new Date() in some android devices only, not in iOS.

Suppose current time in my phone is 11:55 AM (GMT+5:30). Initially new Date( ).getMinutes() returns correct minutes (55 in this case), but when I go to Date & Time Settings in my Phone and change the time zone to GMT-04:00 (2:26 AM) ,I still get the old time in console (Reactotron console). Restarting the phone apparently seem to fix this bug.

Please note that I am not using chrome debugging for logging current time. I am using Reactotron for logging. I am using RN 0.55.4 and android device MI Redmi 4. But this is happening on Samsung devices as well.

I have tried using moment also but that too didn't help. I don't want to write a native module for such a trivial task

Anyone else facing same problem?

[SahRckr]

I suggest this:

1. Test correct time.
2. Change the Device time.
3. Rebuild the application
4. Test time again.

JSCore is not native to Android, It's highly likely that the rebuilding might fix your problem.

[Udbhav12]

@SahRckr Rebuilding might solve the problem but I cannot rebuild the application. I am developing a feature in which if time on user's device is incorrect (Criteria is if the time difference between mobile device time & time sent from server is more than 15 minutes),then I redirect him to Date & Time Settings in Android

[jeremyfrancis]

dateString.replace(' UTC', '').replace(' ', 'T')

Beautiful! Thank you! My database had many 3 letter time endings so I used substring(0,str.length-4) instead of .replace(' UTC','')

[yeomann]

@SahRckr thank you so much mate, i had no idea that JavaScriptCore is causing this problem. your solution was a good fix. thanks for sharing.