DateTime.now oddity?

[MotoMusher]

I hate calling things bugs. I assume this is something I just don't understand.

I have read this thread. http://www.b4x.com/forum/bugs-wishlist/17149-datetime-bug.html#post98040. In that thread at one point last summer, someone said this issue was fixed in a new release. I have version 2.50.

Here is my problem. I have a service which writes a log file with a time stamp every 10 minutes. I then display that timestamp in my activity. It works great.

Dim lastfix As Map
   lastfix.Initialize
   lastfix.Put("LastFix", DateTime.Date(DateTime.now) & " " &  DateTime.Time(DateTime.now))
   File.WriteMap(MyAuth.MyFilePath, "LogLastFix.log", lastfix)

I have had several travelers cross timezones headed east, and the time stamp jumps an hour when the timezone is crossed and matches the time shown by the clock on the phone. This is perfect.

However, the first traveler has now crossed back through the timezone, headed west, to the point he started (his home). The log continues to be written in the eastern most timezone time, not his local time. The time in the file is exactly 1 hour ahead of the phone clock, I have screen shots. The person started and stopped their journey from the same location. Flew east, stayed a day, flew home. This behavior lasted for 2 days.

He rebooted his phone and now he is back on local time.

Any explanations? Is the following code from the thread listed above really the correct way to get a date, or am I missing something?

d = DateTime.DateParse(DateTime.Date(DateTime.Now))
t = DateTime.TimeParse(DateTime.Time(DateTime.Now))
Log(DateTime.Date(d) & " - " & DateTime.Time(t))

 

[Erel]

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

 

[MotoMusher]

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.

StartServiceAt("MyServiceName", DateTime.Now + MyAuth.MinTime , True)

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.

 

[Erel]

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.