Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with times around daylight savings #174

Open
JoeSc opened this issue Nov 1, 2020 · 17 comments
Open

Issue with times around daylight savings #174

JoeSc opened this issue Nov 1, 2020 · 17 comments
Labels
bug Reports of unexpected problems or errors

Comments

@JoeSc
Copy link

JoeSc commented Nov 1, 2020

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

@cdubz
Copy link
Member

cdubz commented Nov 1, 2020

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

@cdubz cdubz self-assigned this Nov 1, 2020
@cdubz cdubz added the bug Reports of unexpected problems or errors label Nov 1, 2020
@cdubz cdubz added this to the v1.4.2 milestone Nov 1, 2020
@JoeSc
Copy link
Author

JoeSc commented Nov 1, 2020

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.

@cdubz
Copy link
Member

cdubz commented Nov 1, 2020

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.

@BenjaminHae
Copy link
Contributor

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

@cdubz
Copy link
Member

cdubz commented Nov 1, 2020

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

@Luzr
Copy link

Luzr commented Nov 1, 2020

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

@amandadebler
Copy link

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

@cdubz cdubz modified the milestones: v1.5.0, v1.5.1 Jan 3, 2021
@cdubz cdubz modified the milestones: v1.5.1, v1.5.2 Feb 25, 2021
@cdubz cdubz modified the milestones: v1.6.0, v1.6.1 May 14, 2021
@cdubz cdubz modified the milestones: v1.6.1, v1.8.0, v1.7.0 Jun 19, 2021
@cdubz cdubz modified the milestones: v1.7.0, v1.7.1 Jul 8, 2021
@cdubz cdubz modified the milestones: v1.8.1, v1.8.2, v1.8.3 Aug 5, 2021
@cdubz cdubz removed their assignment Aug 21, 2021
@cdubz cdubz removed this from the v1.8.3 milestone Aug 28, 2021
@axilleas
Copy link

axilleas commented Oct 31, 2021

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

@cdubz
Copy link
Member

cdubz commented Oct 31, 2021

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 cdubz pinned this issue Oct 31, 2021
@axilleas
Copy link

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

@kdrobnyh
Copy link

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

@cdubz
Copy link
Member

cdubz commented Dec 28, 2021

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

@jcgoette
Copy link
Contributor

jcgoette commented Nov 6, 2022

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

@cdubz
Copy link
Member

cdubz commented Nov 6, 2022

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

@cdubz
Copy link
Member

cdubz commented Oct 21, 2023

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

@cdubz cdubz closed this as not planned Won't fix, can't repro, duplicate, stale Oct 21, 2023
@jschollenberger
Copy link

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

@cdubz cdubz reopened this Apr 11, 2024
@thib3113
Copy link
Contributor

This bug is always here
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Reports of unexpected problems or errors
Projects
None yet
Development

No branches or pull requests

10 participants