DST Discussion - bug

[ghost]

How does it handle daylight savings time? The clock face seems to ignore it showing time an hour behind during DST. Maybe this is a small bug.

[forrestguice]

DST is just another offset specified by the time zone, so it should be drawn correctly. If its not displayed (an hour behind or ahead), its an indication the time zone is misconfigured. There is however a bug on the day of the transition.

Supposing there is another DST bug though, posting a screenshot here would be a great help, so I can track it down.

[ghost]

DST is just another offset specified by the time zone, so it should be drawn correctly. If its not displayed (an hour behind or ahead), its an indication the time zone is misconfigured. There is however a bug on the day of the transition.

Supposing there is another DST bug though, posting a screenshot here would be a great help, so I can track it down.

Do you feel like a moron sometimes? There's no real way to post a screenshot of any valuable information until you answer my opening queatstion: "How does it handle daylight savings time?" then I can take a shot of the clockface and the setting which handles the timezone wheather it be inherent from SunTimes or pulled from android system timezone, but even that would only confirm what I have already typed that the clockface is drawn an hour behind. You asking for a screenshot is really dissapointing and makes me feel like maybe its not worth it to continue with you except that you may be able to read the code and point out the answers to questions which I pose that may SOLVE the problem. If this isn't a DST bug on the part of NaturalHour then it has to do with wherever NH is pulling the timezone maybe then it is pulling from an invisible system setting other than what android™ has shown which is using another timezone, linux works that way many settings pull from multiple paths with uncorrect or no documentation. ...and yes android™ is linux underneath.

Answer me this: where does Natural Hour pull it's timezone settings? Only from Suntimes, from the androidOS, or something else.

[forrestguice]

Do you feel like a moron sometimes?

All the time in fact.

Should I take time to respond to this post? Seems like some toxic stuff if you ask me. Is this how you normally approach people? I didn't volunteer for abuse when I decided to release code under a free license.

[forrestguice]

where does Natural Hour pull it's timezone settings?

Click on the time zone in the lower right corner and it should open a menu. There are several choices. It pulls from the system time zone (TimeZone.getDefault()), or from Suntimes (values supplied by Suntimes ContentProvider). Meanwhile Suntimes has similar options, either using the system time zone, or configure to a specific timezone ID (TimeZone.getTimeZone(id)). The TimeZone objects themselves are whatever is supplied by the Java version running on your device - neither NaturalHour or Suntimes ships its own list of updated zones.

A screen shot would be helpful, because I could see how the app is configured, and maybe flat out tell you there isn't a bug. I thought I was being pretty nice about it. There is always the chance it looks fine (but still drawn incorrectly), in which case I will dig into the code and search for the cause. What I'm not going to do is try to tease the answers out of you.

How does it handle daylight savings time? The clock face seems to ignore it showing time an hour behind during DST. Maybe this is a small bug.

Forgive me for being a moron. This is a vague question. How does it handle daylight savings time? The answer is just fine.

[ghost]

where does Natural Hour pull it's timezone settings?

Click on the time zone in the lower right corner and it should open a menu. There are several choices. It pulls from the system time zone (TimeZone.getDefault()), or from Suntimes (values supplied by Suntimes ContentProvider). Meanwhile Suntimes has similar options, either using the system time zone, or configure to a specific timezone ID (TimeZone.getTimeZone(id)). The TimeZone objects themselves are whatever is supplied by the Java version running on your device - neither NaturalHour or Suntimes ships its own list of updated zones.

A screen shot would be helpful, because I could see how the app is configured, and maybe flat out tell you there isn't a bug. I thought I was being pretty nice about it. There is always the chance it looks fine (but still drawn incorrectly), in which case I will dig into the code and search for the cause. What I'm not going to do is try to tease the answers out of you.

How does it handle daylight savings time? The clock face seems to ignore it showing time an hour behind during DST. Maybe this is a small bug.

Forgive me for being a moron. This is a vague question. How does it handle daylight savings time? The answer is just fine.

You are breaking up with your use of grammar here. Anyway, The timezome was set to Apparent Solar Time and appeared an hour behind my system time I was guessing the inner hash ticks were representing my system time because the outer ring's variable length hours are already apparent solar Time, yes this is a BIG BUG you have a completely wrong timezone AST. Because it is wrong it lead to misreading. I looked at the apparent solar Time (outer ring) and then see another timezone inner hash ticks while seeing AST in the center which at first use I credited for the correct outer ring which is AST but you have a false AST showing. Now I will report the bug , you according to your report here attribute to java objects, that java is to blame for a false AST timezone. If such is true you would be able to blame android-java for the false AST. Yet even then you should have caught the false timezone displaying and not supplied the option to select a false timezone as the default for the latest app release in this is YOUR BUG.

[forrestguice]

according to your report here attribute to java objects, that java is to blame for a false AST timezone.

I didn't say that. What I said was the time zone definitions are supplied by the system, and those definitions are shipped (and updated) as part of Java. If those definitions are out-of-date then it would explain why DST wasn't applied correctly. I never mentioned the "solar time" options, which are in fact special cases (a series of offsets applied to UTC).

If you had skipped the hostilities and instead provided a screenshot, then I could have spotted the "problem" right away. As far as I can tell there is no bug and this is a misunderstanding on your part. I would suggest you read more about "apparent solar time" and then look closely at the output provide by the app. A hint.. solar noon occurs when the sun is directly overhead (your sundial will read '12'), is offset from "local mean time" by the "equation of time" (eot), which is then offset from UTC by longitude.

I consider myself generous with my time, but I won't be wasting any more of it on this particular interaction. I've temporarily blocked your participation here and on my other repositories. That is a shame, because I do get the impression you have potential to contribute in a positive way (#17). I will review and clear this block in the coming months. If you choose to participate here in the future, I would ask that you please work on your communication skills.