• (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).

  • (nodebb) 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.

    If only databases had a data type for timestamps that includes the time zone as part of the data.

    Oh, wait

  • Snarkenstein (unregistered) in reply to 516052

    Oh, 516052, sweet summer child. As a database administrator and programmer for close to three decades, I can tell you: I wish it would happen that way in the real world.

    I have the scars to prove it.

  • (nodebb)

    "...Americans (where they put the currency symbol first with commas to separate thousands etc. for everyone)." But being Americans, we can't always do it that way. If the value is expressed in Cents, then the currency symbol goes after the number. Yay us.

  • MangusPI (unregistered) in reply to Steve_The_Cynic

    culturally insensitive treatment of such things as perpetrated by Americans

    This feels really unfair. I have seen far more transgressions of this type from abroad to be honest, and given that a lot of the localization mistakes observed in recent time has been from APIs, portals, and other such software vendors, many of which wasn't even written by Americans, but used by them and others, so in those cases it's clearly misplaced blame (so long as it got rectified when brought to attention in a timely manner.)

    I really wish people would stop blindly blaming Americans for everything when there is plenty to go around.

  • Hmmmm 🤨 (unregistered)

    Speaking of using functions/methods, once code reaches a "choose-your-own-adventure" level of if /else / switch / for statements, it's time to start refactoring it into functions with very meaningful function names.

  • (nodebb) in reply to jkshapiro

    Yeah, I liked that multiclosing brackets bit as well. Then I thought, hey what if this were python and one tab was in thewrong place?

  • (nodebb) in reply to n9ds

    Well, sure, since we need to keep the 'number' part of our money connected. Thus $ 45.43 [cents mark]
    Yes, I know we don't do this but we could...

  • Officer Johnny Holzkopf (unregistered)

    In the EU, the Euro currency representations range from 15,- € over EUR 4.500 or even 7 500 EUR and 125 Euro to 99,95 EUR. Zero cents can be left out or have the equivalent of ",-" ("and nothing"). You even sometimes see Euro symbol prefixes like € 134,99. While the decimal separator commonly is ",", the thousands separator can be left out, be ".", or a single space " ". This is not really specific to a country, but can even vary within one shop. And sometimes, you can see nonsese like 2,99,- € ...

  • 516052 (unregistered) in reply to Snarkenstein

    There is a reason why I said "the way I taught it" and not "the way I've seen it done". One is a nice theoretical pattern that you wish you would see in reality. The other is a Pandoras box of nightmares that robs my nights of their dreams.

  • no (unregistered) in reply to Dragnslcr

    from the page linked:

    For timestamp with time zone values, (. …) the value is stored internally as UTC, and the originally stated or assumed time zone is not retained.
    For times in the future, the assumption is that the latest known rules for a given time zone will continue to be observed indefinitely far into the future.

    storing timestamps this way is correct when you want to represent an exact point in time and have it remain the same point in time no matter what. this is what you need most of the time, but not if you want to store a specific local time in a specific timezone and have it remain the same local time when politics change what “local time” means with respect to UTC.

    timestamps stored in a column of type timestamp with time zone (timestamptz) would exhibit the issue from my comment where the UK switching to permanent summer time would mean the calendar event silently changes from 19:00 to 18:00 local time.

  • SumYungGai (unregistered)

    On a different note, where's today's (2027-08-28) Errord article?

  • Fizzlecist (unregistered) in reply to n9ds

    That's not just an American thing for once - many countries do exactly the same thing

  • MangusPI (unregistered) in reply to Fizzlecist

    thing for once

    Honestly there are just as many things to complain about in European and Asian policies and SOPs.

Leave a comment on “The Big Family”

Log In or post as a guest

Replying to comment #703799:

Log Out

« Return to Article