babybuddy
babybuddy copied to clipboard
Issue with times around daylight savings
I was just up feeding my child and got an error saying.
2020-11-01 01:06:00 couldn’t be interpreted in time zone America/Chicago; it may be ambiguous or it may not exist
The above error was generated from the '+' -> 'Diaper Change' page.
I assume this has to do with daylight savings. Since even I don't know if right now is the first or second time it's 1:06 am...
Oaf. Sorry to hear that. I’ll see if I can reproduce and figure out what’s happening there. Damn DST...
Interestingly the "Time fill in popup" has two "01s" in it
So it looks like "time fill in popup" understands the proper time, might just be how you are interpreting the data that is submitted.
The error occurred for you when you got to the form, correct? I.e. not when you submitted the form? I’m guessing this has something to do with logic relating to prefilling the date field values when the form is loaded.
For me it came after submitting a timer started during the second hour between one and two.
Thanks @BenjaminHae. I’ll check that out as well. Looks like this is reproducible even now by selecting a time between 1 and 2a —

Same issue for Chicago Timezone.
I saw the same thing during Europe's time change a few weeks ago
👋 any workarounds on this? Seems I cannot use a time between 2am-2:59am the day time changes (Europe/Paris).
btw I'm getting this when submitting the form.
No workarounds I can think of. I can’t believe this bug report is a year old. I hate to say “soon” but I will try to address this… soon 😬
Yeah, I know :smile: No worries, the current workaround is to not file any reports during this hour :)
@cdubz, just an idea: why not to store everything as UTC in the database and convert from/to for every data that it stored/retrieved?
@kdrobnyh date and time data in the database is stored in UTC but we handle the timezone server side based on application or user settings. I think ideally we could move that handling to the frontend but thats no small task.
Wife reported this issue this morning. I'm thinking this probably isn't an issue when DST begins, only even it ends?
Oh maybe... I thought it was both but, again, I haven't taken the time to dig in to this one 😬
Hoping this is no longer an issue in v2 now that a library is no longer being used for datetime entry :crossed_fingers:
We encountered this issue this morning on v2.1.2.
From 1 until 2AM we couldn't log feeds:
2023-11-05 01:21:53 couldn’t be interpreted in time zone America/New_York; it may be ambiguous or it may not exist