2

I found what was wrong:

So apparently http://www.epochconverter.com/ is makes assumptions of the precision of the input values, and from those assumptions values around 841073068 goes to 1996/1997. I'm not sure what is the assumption that leads to that exact date, but honestly I don't care.

Using the attached debugger I called new Date(System.currentTimeMillis()) and it correctly gave me a 10th Jan-1070 date, meaning the clock is not jumping out of the way like crazy.

Original question:

I'm running a single-board computer with Android for and IoT case (this https://developer.qualcomm.com/hardware/dragonboard-410c). The OS running is the plain vanilla Android supplied by Qualcomm.

Currently I'm testing the reliability of the board to be left executing for long periods at once and I'm seeing some very very weird behavior that I can't find an explanation for.

The board was powered up 10 days ago and it have no access to internet (WiFi is on but no access point setup and no Ethernet). The bluetooth is on and there're iBeacons and Eddystone in the office. Also there are WiFi in the area.

If I go now to Settings -> Date and Time, or check the notification shade or enter the clock app, or the calendar app, I see 10th of January 1970. Which is expected and basically showing for how long the board been running.

The app on it have an always running service, which does some data processing and some disk-logging (for debugging).

From the logs, I can see that System.currentTimeMillis() was returning an expected value when the board was initially powered on. That means, the beginning of the logs indicate an epoch time in January 1970.

But at the end of the logs (and also attaching the debugger on the live process), the value of System.currentTimeMillis() is somewhere in Sep/Oct 1996. Example values: 841073068, 841263234, 841579239

So my question is:

  • What is happening here?
  • Why System.currentTimeMillis() value changed and what could have changed it?
  • Why the Android UI (notification, clock app, settings) still shows me 1970? Where are they getting this value from?

edit:

There's been some confusion on the answers, and I can see my question was lacking the details.

I do not want to measure difference of time. I need an actual time stamp. Those values will be reported with bluetooth LE events via POST to our backend. This "no network" thing is a reliability test that we're running on the board, but we do expect to have network most of the time, and the boards should auto-update their times from network using the normal Android ways.

I'm just trying to understand on the current batch of testing, what went wrong and why.

Richard Chambers
  • 16,643
  • 4
  • 81
  • 106
Budius
  • 39,391
  • 16
  • 102
  • 144
  • Weird behavior, I often find bugs in software where the system time is nowhere close to the real-time. I personal tend to avoid a system time which is off by this far. Anyway, this question seems offtopic for this forum. You might wan't to send a bug report to the manufacturer or Google. – Rolf ツ Jan 02 '17 at 10:34
  • @Rolfツ I understand your reason for considering off-topic, but as I see, there could be some programming reason for it that I didn't consider. Normally I would also eliminate far off clocks, but as this is a reliability test on behavior when when connection is spotty, it's important to dig and be aware of the system limitations. – Budius Jan 02 '17 at 10:40

2 Answers2

1

Well, as you already know, the current system time (System.currentTimeMillis()) can be modified by any process if desired, it's perfectly be possible that it was modified by another process. It's not a reliable method to measure up-time.

I would rater use something like:

SystemClock.uptimeMillis()

Which returns the elapsed time (in milliseconds) since the device booted (not including time spent in deep-sleep).

I would also like to mention that I suspect that Bluetooth has something to do with it, I can imagine that Bluetooth uses the system time for pairing and security just like SSL does (but I'm no expert). GPS could also be a problem as GPS can be used to obtain an UTC time value, but I'm not sure if your board has a GPS module.

Regarding your edit:

Obtaining a valid time-stamp would be quite easy: server time minus the elapsed time reported by your board. But I suggest you either choose to accept the time reported by System.currentTimeMillis() or use the elapsed time instead. At the company I work we also work with embedded Android devices and on our server dashboard we can see both the up-time (up since) and the current device time, but they should not be mixed, at least in my opinion, especially since System.currentTimeMillis() is subject to changes and is affected by summer and winter time.

Rolf ツ
  • 8,611
  • 6
  • 47
  • 72
  • I'm also suspicious of the Bluetooth, but our process is not pairing with anything, only doing Bluetooth LE scans. The board have GPS, but we're not doing anything with it and it's inside an office, I doubt it could get any signal. Also please check the edit on my question – Budius Jan 02 '17 at 11:02
  • Thanks for your answer/comments. See edit at top of my question, I found what was going on. We don't mix uptime and currentTimeMilis. But is just that we need reported on the dashboard the time the scan event occurred, if the board got rebooted, or went to sleep it doesn't matter, in general the date should be kept on the devices normally via NTP, it's just that network down that lead to 1970. – Budius Jan 02 '17 at 12:59
0

If you want to measure something, better try System.nanoTime(). Here is difference - https://stackoverflow.com/a/351571/2793494

Community
  • 1
  • 1
Yurii Kyrylchuk
  • 809
  • 7
  • 16
  • Thanks for your answer, but that's not really what I'm looking for, please read the edit on my question. Tl;DR is. I really need the timestamp and that's only a test for now. – Budius Jan 02 '17 at 11:00
  • see edit at top of my question, I found what was going on. – Budius Jan 02 '17 at 12:56