You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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".
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
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: