Artox
commented
12 years ago Apparently I just ran into a similar problem. on first boot, I kept automatic timezone set to 'ask' and it offfered me this GMT-32 time as it was supposedly reported by the network. Applying this time(which is kinda pointless considering the weird number), I get my system time to epoch too. I am using a gta02. I never had that before, 'ask' settign never did anything to me so far but now I switched the provider. Therefore I am in O2 net now.
The string displayed for the date is apparently empty, and if I answer yes, my time is reset to the Epoch, with an attempt to use timezone "GMT-32" (curiously, that does not work ;)
Apr 12 22:37:47 TimeZoneData::fromUtc invalid Jan 01 00:01:04 Could not copy "Etc/GMT-32" to localtime Jan 01 00:01:04 Time : Etc 0 ... Jan 01 00:01:06 Time : Etc 0 Jan 01 00:01:13 Unable to open '/usr/share/zoneinfo/Etc/GMT-32' Jan 01 00:01:13 QTimeZone::data Can't create a valid data object for 'Etc/GMT-32' Jan 01 00:01:13 Unable to open '/usr/share/zoneinfo/Etc/GMT-32' Jan 01 00:01:13 QTimeZone::data Can't create a valid data object for 'Etc/GMT-32'
Logging shows that the modem reports a timezone change without telling the time, with "+CTZV: 128" (justafter receiving a "+CGREG: 5" indicating "registered, roaming".
1st identified problem: According to http://www.scribd.com/doc/63648056/149/AT-CTZR-Time-and-time-zone-reporting only providing a timezone is valid, and QtMoko apparently assumes it will necessarily have a time
2nd identified problem: 128 probably cannot be interpreted as a legal number of quarters of an hour. Until we know what this value means (could not find through a quick googling), we should refuse the TZ change and not tell the user - maybe just write a trace.
3rd identified problem: /etc/timezone does get stuffed with an invalid tz name (here "Etc/GMT-32"), even when we could check that the timezone we want to set is indeed invalid