react-native -v: 0.48.1node -v: 8.0.0npm -v: 5.4.0yarn --version: 0.24.6_Have not tested on Android device, but may apply too_
console.log(new Date()); anywhereWe stumbled upon this testing issues in our application when users' device time is not correct.
When we were debugging remotely we were baffled because our logs always showed the correct time, even when we manually changed the date and time on the device.
Expectation would be that new Date() would reflect the mobile device even when remotely debugging to aid debugging issues that arise from a user having their date and time offset from actual.
This is expected behavior. When debugging remotely, your js bundle is using chrome's jsc and when running on device it's using the jsc provided by apple on your phone.
I understand this introduces some gotchas and i think it's always best to double check the app on a real device.
While your explanation for why it is happening makes perfect sense, the idea that is expected behavior is not adequate, in my opinion.
As explained by my use case, it's very difficult to debug a device with the incorrect time because of the mechanism you described. If there were a way to workaround this or write a patch that would use the device time to help debug these types of issues, I believe it would be useful for my current project, and others as well.
i'm worried about making exceptions when using browser jsc. This would only lead to more confusion down the road. I think this project is not using browser jsc: https://github.com/infinitered/reactotron. Try using that. i'm not sure if that will actually solve your problem tho.
I believe that @jasongaare is reasonable. This should not be labeled as a feature but rather as a bug because it might be really confusing for new react-native developers to understand why is this happening. Also, it makes debugging a lot harder in general.
Most helpful comment
While your explanation for why it is happening makes perfect sense, the idea that is expected behavior is not adequate, in my opinion.
As explained by my use case, it's very difficult to debug a device with the incorrect time because of the mechanism you described. If there were a way to workaround this or write a patch that would use the device time to help debug these types of issues, I believe it would be useful for my current project, and others as well.