babybuddy icon indicating copy to clipboard operation
babybuddy copied to clipboard

Issue with times around daylight savings

Open JoeSc opened this issue 3 years ago • 16 comments

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...

JoeSc avatar Nov 01 '20 07:11 JoeSc

Oaf. Sorry to hear that. I’ll see if I can reproduce and figure out what’s happening there. Damn DST...

cdubz avatar Nov 01 '20 12:11 cdubz

Interestingly the "Time fill in popup" has two "01s" in it image So it looks like "time fill in popup" understands the proper time, might just be how you are interpreting the data that is submitted.

JoeSc avatar Nov 01 '20 14:11 JoeSc

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.

cdubz avatar Nov 01 '20 14:11 cdubz

For me it came after submitting a timer started during the second hour between one and two.

BenjaminHae avatar Nov 01 '20 15:11 BenjaminHae

Thanks @BenjaminHae. I’ll check that out as well. Looks like this is reproducible even now by selecting a time between 1 and 2a —

PNG image

cdubz avatar Nov 01 '20 15:11 cdubz

Same issue for Chicago Timezone. 2020-11-01_09-41-27

Luzr avatar Nov 01 '20 15:11 Luzr

I saw the same thing during Europe's time change a few weeks ago

amandadebler avatar Nov 14 '20 08:11 amandadebler

👋 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.

axilleas avatar Oct 31 '21 03:10 axilleas

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 😬

cdubz avatar Oct 31 '21 04:10 cdubz

Yeah, I know :smile: No worries, the current workaround is to not file any reports during this hour :)

axilleas avatar Oct 31 '21 10:10 axilleas

@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 avatar Dec 28 '21 16:12 kdrobnyh

@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.

cdubz avatar Dec 28 '21 17:12 cdubz

Wife reported this issue this morning. I'm thinking this probably isn't an issue when DST begins, only even it ends?

jcgoette avatar Nov 06 '22 12:11 jcgoette

Oh maybe... I thought it was both but, again, I haven't taken the time to dig in to this one 😬

cdubz avatar Nov 06 '22 16:11 cdubz

Hoping this is no longer an issue in v2 now that a library is no longer being used for datetime entry :crossed_fingers:

cdubz avatar Oct 21 '23 00:10 cdubz

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

jschollenberger avatar Nov 05 '23 12:11 jschollenberger