• (nodebb)

    What is the $mot array?

    Most likely an array of words ("mot" (fr) == "word" (en)), presumably loaded somewhere depending on the selected language, the phase of the Moon, the phase of Venus as seen from Mars, the colour of the user's socks, or some other criterion I cannot imagine.

    Also, that code block shows a different problem - it formats currency as {numbers} {symbol} e.g. 1 946,27 €. It's an inversion of the usual culturally insensitive treatment of such things as perpetrated by Americans (where they put the currency symbol first with commas to separate thousands etc. for everyone).

    And then there's this little treat for parsing the time stored in our database: $time_data = json_decode($resm_details->time_data); That tells me they're storing date times as strings, so that's fun.

    It tells me they are storing date-times as strings containing JSON.

  • OldCoder (unregistered) in reply to Steve_The_Cynic

    Um, excuse me? In the UK we use currency symbol first followed by numbers separated by commas. I suspect a lot of places that used to be in the British Empire do. Unusually, it isn't an American thing.

  • no (unregistered) in reply to Steve_The_Cynic

    at a previous job, there was a reason to store datetimes in json: calendar events.

    if your user schedules an event (dinner reservation?) for 19:00 on 14 february 2027 in the timezone Europe/London, they presumably want the event to happen at 19:00 even if e.g. the UK switches to permanent summer time, thus using UTC+1 all year.

    a unix timestamp does not carry timezone information, and the same timestamp would represent 18:00 local time after the change. a datetime with a UTC offset would remain in UTC+0 after the change, and thus also happen at 18:00 local time.

    storing both a datetime and a timezone, e.g. as {"time":"2027-02-14","timezone":"Europe/London"} would ensure the event happens at 19:00 local time even after the (political) change of permanently using summer time.

    sure, the datetime and timezone could be stored in separate columns in the database, but i find a single column more appropriate. it makes little sense to only read/write one of them, or to sort/filter by only one of them. they would always be deserialized from the database together, added to forms together, etc.

  • (nodebb) in reply to OldCoder

    Unusually, it isn't an American thing.

    Fair point, although the British don't seem quite so compelled toward cultural insensitivity as the Americans do.

  • TechHound (unregistered) in reply to Steve_The_Cynic

    Also, that code block shows a different problem - it formats currency as {numbers} {symbol} e.g. 1 946,27 €. It's an inversion of the usual culturally insensitive treatment of such things as perpetrated by Americans (where they put the currency symbol first with commas to separate thousands etc. for everyone).

    Honestly I have seen far more European countries get international localization wrong than the US in recent years, so please spare us this ridiculous cliché.

  • TechHound (unregistered) in reply to Steve_The_Cynic

    although the British don't seem quite so compelled toward cultural insensitivity as the Americans do.

    Sorry, but that is such a load. Europeans do that sort of thing all the time. You sound like you are looking through a very narrow lens while painting with comically large brush. Glass houses and all that apply.

  • (nodebb)

    There's something satisfying about this cascade at the end of it all.

                            ]);
                    }
                }
            }
        }
    }
}
  • 516052 (unregistered) in reply to no

    sure, the datetime and timezone could be stored in separate columns in the database, but i find a single column more appropriate. it makes little sense to only read/write one of them, or to sort/filter by only one of them. they would always be deserialized from the database together, added to forms together, etc.

    This. Fundamentally the way I've always taught it was that each row is one record and represents one "thing". Where as each column represents one piece of information about that thing. So a column can be as little as a single bit or as long as a whole essay what matters is that in the schema the piece of information it represents is discrete (does not overlap with other columns) and atomic (can not be divided into subcomponents that make sense).

Leave a comment on “The Big Family”

Log In or post as a guest

Replying to comment #703759:

Log Out

« Return to Article