Timeline for Is the frontend or backend (API) responsible for formatting data in a specific locale?
Current License: CC BY-SA 4.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S Feb 17, 2022 at 5:25 | history | suggested | Andreas ZUERCHER | CC BY-SA 4.0 | expanded example to demonstrate the depth of the answer versus the inefficiency/overhead of the alternative |
| Feb 9, 2022 at 16:01 | comment | added | Matthieu M. | Let us continue this discussion in chat. | |
| Feb 9, 2022 at 15:29 | comment | added | IMSoP | @MatthieuM. Well... what I want in that case is the absolute time that the flight will actually depart. Most likely, when Morocco made that change, flights didn't all depart an hour early to meet the published "local time" (they might not physically be there yet!), but departed at the originally planned absolute time. So your "14:35" departure (scheduled assuming Winter Time) would actually depart at 15:35 according to the local clocks (still on Summer Time). So as it happens storing the 14:35 with a UTC offset would have given the right answer, and re-calculating by location would not. | |
| Feb 9, 2022 at 14:56 | comment | added | Matthieu M. | @IMSoP: Definitely hard. Also, you want location, not timezone because locations change timezones over time due to political events... | |
| Feb 9, 2022 at 14:56 | comment | added | Matthieu M. | @IMSoP: (cont.) So, how to store the time? Well, it depends on the usecase. If the user wants a meeting at 10 AM in Rabbat (Morocco) that's what they want, and storing in UTC will put you in for a world of pain should Rabbat switch timezone quickly -- like, because the King of Morocco decided to scrap Winter Time, less than 2 days before it was due in 2018 (BBC). | |
| Feb 9, 2022 at 14:54 | comment | added | IMSoP | @MatthieuM. Hah, fair point - it would save pain for some things (e.g. "send the customer an SMS 2 hours before their flight" is impossible if you don't know an absolute time), and cause it for others. I guess the real answer is that Timezones Are Hard™ | |
| Feb 9, 2022 at 14:50 | comment | added | Matthieu M. | @IMSoP: "Nonetheless, I agree that back-end systems should store and return UTC, converting to local time only when displaying to a human; it would save a lot of pain!" Would it? If I schedule a meeting at 9am in 3 months, and my country decides to stop doing DST, I still want the meeting at 9am regardless, because at 8:00am I'm dropping the kids to school! One reason that airlines always talk in local time, is that many things are done in local times: opening hours of the various businesses, curfew (thanks COVID), etc.. are all in local times (cont.) | |
| Feb 9, 2022 at 13:53 | comment | added | IMSoP | @pjc50 You may be horrified to hear that airline systems (and the travel industry generally) often store and transmit times local to the airport of arrival/departure, usually without any indicator of timezone at all. If you want to know the duration of a flight, and it's not provided directly, you have to maintain your own lookup table. Nonetheless, I agree that back-end systems should store and return UTC, converting to local time only when displaying to a human; it would save a lot of pain! | |
| Feb 8, 2022 at 21:59 | comment | added | Mark Foskey | @ShmuelNewmark The example involving sorting did not involve dates. The person was considering other things besides dates that might depend on local conventions, and the order for sorting words might be one of those things. | |
| Feb 8, 2022 at 16:07 | comment | added | pjc50 | For timezones, you should generally store UTC* and display local, if possible. Think hard about where "local" is. Airline reservation websites tend to display each leg as local to the airport where the arrival/departure is. | |
| Feb 8, 2022 at 16:04 | comment | added | pjc50 | @ShmuelNewmark date/time ordering should not be locale dependent, although in that case you have far worse worries about timezones. I was talking about alphabetical order; things like the Turkish i and letter Ø sort differently depending on your locale. | |
| Feb 8, 2022 at 15:48 | comment | added | Voo | @TripeHound That's the opposite of the problem that pjc describes. Say you have a list of names and want to return the first N sorted. That requires the client to send their locale to the backend. | |
| Feb 8, 2022 at 15:24 | comment | added | TripeHound | @ShmuelNewmark If the client-side code needs the ability to sort a table/list locally, and returned dates have already been localised as dd/mm/yyyy or mm/dd/yyyy then it's less convenient to sort them than if they were returned as yyyy-mm-dd or seconds (or whatever) since some epoch. | |
| Feb 8, 2022 at 13:56 | comment | added | Shmuel Newmark | I'm having trouble visualizing when you would sort Date/Time by anything other than before and after which wouldn't be locale dependent but I don't have much experience. Can you give some examples please? | |
| Feb 7, 2022 at 16:57 | review | Suggested edits | |||
| S Feb 17, 2022 at 5:25 | |||||
| Feb 7, 2022 at 11:24 | history | edited | amon | CC BY-SA 4.0 | explicitly mention what 1 and 2 mean |
| Feb 7, 2022 at 10:52 | history | answered | pjc50 | CC BY-SA 4.0 |