Lundalogik
Date-only strings are displayed as local time but parsed as UTC
The date-picker widget used in limel-form parses date format strings as UTC, by just passing them to the Date constructor, but displays and handles dates as local time after that.
This is usually not a problem in Europe where we have a positive time offset, for example:
> new Date("2023-04-13")
Thu Apr 13 2023 02:00:00 GMT+0200
but in the US, the local date will be 12 April.
I have an issue where someone in the UK (GMT+0000) saves "Apr 2023" in a month field in CRM. As you know, we store this as 2023-04-01 00:00:00 in the database. Do we also include the time zone there? However, the web client somehow interprets this as "March 2023". My guess is that it is because the time in Sweden is 2023-03-31 23:00:00 when it's 2023-04-01 00:00:00 in the UK 🤦♂️ . I think this is the same error that people in Finland (one hour ahead of Sweden) are.
If my analysis is correct, I think we should do it like this: Always ignore the time part when not showing time. In other words, these date field types:
- date
- week
- month
- quarter
- year
should be "calculated" in the client by doing Datepart("month", 2023-04-01) and not Datepart("month", 2023-04-01 00:00:00) or Datepart("month", 2023-04-01T00:00:00+02:00) or whatever it is we do. We have "invented" false data when we say that "Apr 2023" = "2023-04-01T00:00:00+02:00". It is too many "significant figures" (gällande siffror). We need to ignore that "invented" data when needed.
As you know, we store this as 2023-04-01 00:00:00 in the database. Do we also include the time zone there? However, the web client somehow interprets this as "March 2023".
Yes, we include timezone, at least when looking at the date strings that we send to and receive from the server. I'm surprised by that behaviour if the user that saves the field is indeed in the UK. I would rather guess a user in Sweden saved the date as 2023-04-01T00:00:00+02:00, which then would be 2023-03-31 22:00 in the UK. I don't see anything in lime-elements that could explain the behaviour that you describe, but it's possible we mess with the time offset on the server in some way.
If my analysis is correct, I think we should do it like this: Always ignore the time part when not showing time.
Yes, I agree. While not exactly the same issue as with date-only strings, I think it makes sense to ignore the time and offset when it's 00:00:00+02:00 and the date picker type doesn't include time.
It might not be that simple always though. It's reasonable to assume that the time offset is lost when serializing and then deserializing the date. For example, new Date("2023-04-01T00:00:00+02:00").toJSON() returns "2023-03-31T22:00:00.000Z"
If we assume the date is always saved with local time 00:00:00, it's possible to figure out the local date still.
If we assume the date is always saved with local time 00:00:00, it's possible to figure out the local date still.
To avoid making that assumption, the alternative I guess is to emit changed date values as 00:00:00 UTC when serializing and convert that to local date when parsing. This would be a breaking change to some extent though I think, and might not work if the server always responds with its local time for some reason.
:tada: This issue has been resolved in version 37.59.0 :tada:
The release is available on:
Your semantic-release bot :package::rocket:
