When I don’t enter my text for a datapoint when submitting with beedroid, the autogenerated entry is along the lines of “via beedroid at 07:41:32 CST”. Which is completely reasonable except that I am not in CST, I’m in CDT, because daylight time is active in my locale. I don’t know if “phone is observing daylight time” is necessarily exposed to beedroid, but I’d rather see no time zone at all (and just thus infer that it was “local time”, whatever that meant when I submitted) than an incorrect one.
This isn’t just an academic/trivial difference: Saskatchewan, e.g., is actually in CST right now: they’re currently GMT-6, whereas I, in the US, am currently GMT-5. I imagine the set of impacted users—those who regularly travel between CST/CDT areas in the same week, or correspondingly between MST/MDT (e.g. people who live near the Arizona border?), etc, is rather small, but I also imagine it’s not quite zero? Whether this matters to them is another question, but still: a bug.
Hmm, interesting. What timezone does your Beeminder account say you’re in? Looks to me like it’s saying CDT/GMT-5, so not sure where Beedroid’s getting it from!
Hmm! Under “Account Settings”, I’m seeing “(GMT-06:00) Central Time (US & Canada)”. Which… I’m certainly Central Time (US & Canada), but that’s only (GMT-06:00) part of the time. I see there’s separate entries for Arizona vs Mountain Time, and for Saskatechewan vs Central Time, so clearly the options are time zone aware—and, y’know, Beeminder does show times correctly for me.
But perhaps it’s just as simple as each of these options has exactly one “short name” set for it? I should note that beedroid is recording the actual correct time: when my clock and phone say 10:00, so does beedroid’s data point… it just puts the wrong short name after it.
The bug is that the “get the shortname for the timezone from the locale” function takes in a parameter “should I use DST or not”, and we have it hardcoded to false, instead of “well, does the timezone use DST right now or not?!?!”