• (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
    Comment held for moderation.
  • 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.

Leave a comment on “The Big Family”

Log In or post as a guest

Replying to comment #703759:

« Return to Article