- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Edit Admin
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).
It tells me they are storing date-times as strings containing JSON.
Admin
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.
Admin
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.
Edit Admin
Fair point, although the British don't seem quite so compelled toward cultural insensitivity as the Americans do.
Admin
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.