DateTime.now oddity?

The timezone is set once when the application starts. It will only be updated after the process is recreated.

You can add an intent filter and listen to this action (see the intent filters tutorial): android.intent.action.TIMEZONE_CHANGED

Thank you for your response Erel. I really appreciate it. I will review intents further tonight. The static receiver explanation makes sense to me, but only if the service was failing to launch? I have to read it a few more times.

I am struggling trying to understand why it appears to be inconsistent (at least to me). My suspicion was that the timezone was only "checked"at app startup as you stated and would expect that all portions of the app would then have that timezone applied to datetime.now. 3 factors are contradicting this in my head, I am one of those "need to understand" kind of people.

1. If timezone is only established at app startup, how did it jump "ahead" when the traveler crossed eastbound? (US Central to US Eastern) . User states phone was not rebooted, nor another version of the app installed, during the entire trip. Sometimes users are unreliable I know, but this is an engaged users, and an engineer who has volunteered as a test subject. I have no reason to doubt his findings like I may with some others. Perhaps that is where I am going wrong with this.

2. The service, which writes that log file, restarts itself on a 10 minute interval with servicestartat and stops itself at the conclusion of the sub. That continued to work perfectly through the whole process. I have all the logs and it fired every 10 minutes both east and west. Only the visualized time in the log file was inconsistent with what I would expect.

This is the code from within the service that is writing the timestamp file, calling itself recursively.

If datetime.now is stuck in the wrong time zone, would it not be setting the alarm in the "past" since as I understand it the startserviceat is external to the app and is part of the OS (I may be wrong here)? Me sending a time value to another process with a value technically in the past, I would think would cause it not to run?

3. I don't fully understand the android lifecycle yet, but the OS is killing the starting app since it may only be opened a few times a day. I planned for this. I would think the startserviceat would cause the service to run independently, rather than under the original context which started it after numerous independent start/stops? I would also think that re-launching the interface portion of the app 12 hours later would then re-establish the correct timezone if it had been shut down by the OS?

Thanks again. Basic4Android has really exceeded my expectations so far. Especially after struggling with eclipse for a while.

I think that it is best if you try your program while manually changing the time zone. You should be able to see the effect.

If the process was killed by the OS and then recreated then the new timezone will be used.