Comment 2 for bug 1240434

I'm not entirely convinced that this is a bug in system-image, so let's explore it a little bit (if you can still reproduce it).

s-i gets it's "last update date" from the mtime of one of three files. The first of these files that it finds, it takes the mtime and converts that to a date string of the format you show. The files are:

/userdata/.last_update
/etc/system-image/channel.ini
/etc/ubuntu-build

So the first thing to do is to ls -l each of these files (via adb shell) and see if any of them give you an mtime matching 1970-01-01 02:04:36.

What's strange is that date. We use Python's datetime object to convert from a POSIX timestamp to a timestamp string. If I run the conversion in reverse, it means that the file would have to have kind of a weird timestamp:

>>> d = datetime(1970, 1, 1, 2, 4, 36)
>>> d.timestamp()
7476.0

(Note that this would be slightly different on amd64, so try that on your device).

Why *that* number?

Note that if let's say the mtime were 0, we'd get a different timestamp:

>>> d = datetime.fromtimestamp(0)
>>> print(d)
>>> d = datetime.fromtimestamp(0)
>>> print(d)
1970-01-01 00:00:00

Which is off by 2h4m36s. I suppose it's possible that some mobile devices would return different values for timestamp 0 (just as it does on amd64). Be sure to test this with Python 3.

If that's the case, then identifying which of the three above files exists and has the bogus mtime will be key to debugging this.

Another possibility. Let's say that none of those files exist (for some inexplicable reason). system-image-dbus in that case will return the string 'Unknown' as the timestamp. Can system-settings handle that? I wonder if when it sees 'Unknown' it returns the bogus date string?

Anyway, I can't reproduce this, nor can I see how it would even be possible, so more information is necessary.