> It's going to be fun to watch developers wrap their heads around that one...
No, it will not. Nobody gives a damn. Nobody will implement it.
I am still trying to get people to correctly denote beginning and end of a day (much more useful, practical). Everybody I work with seems to be bent on using 23:59:59 as the end of the day rather than start of next day. Explaining that there is no 1s delay between end of one day and start of the next isn't helping either.
Sit on my lap youngling, and I will tell you tales of i18n horror... and I'm from an English-speaking country!
A realistic scenario is an Australian writing French poetry while on holidays in Turkey. Now you have an OS GUI with en-GB as the language, licensing and date/number formatting as per the AU region, French spelling dictionary, a US-101 keyboard layout, Turkey as the location, and GMT+3 as the time zone.
It's a rare piece of software that can handle this. Few vendors have staff that have even heard of such exotic places.
There are still people... many people... that deny the existence of places outside of the United States of America. Such filthy, heathen locations are surely a thing of myth, or legend!
Places where dates are formatted with the days before the month, followed by the year in some sort of weird, unnatural order.
Nations that have fallen into the trap of some sort of mass hallucination, or shared dream of common measurement units. Some sort of... metric, for space, time, and matter. Maybe they've been watching too much Star Trek!
Multicultural countries where strange unions of races are commonplace, and couples may want to watch Netflix in one language, but have subtitles in a different language. Neither of which are English for the hearing-impaired! Surely, nobody but the deaf are unable to comprehend the universal English language! Not to mention that such taboo couplings are, thankfully, still banned on this stream of holy virtue and shall not be permitted by the data scientists that have declared: "Your union is a statistically negligible!"
> There are still people... many people... that deny the existence of places outside of the United States of America.
Two fun anecdotes my mother has recounted when we were all in Denver for ~5 months in Denver 1996:
1. Asked where we were from on one occasion (after hearing an Australian accent): “Australia.” Response: “Oh, did you come by bus?” Now it is possible that there was a misunderstanding there, but mum doesn’t think so.
2. Of those that didn’t already know, only one person successfully identified where we were from, and that person was deaf. (It’s fascinating to try something like this on video without audio where there’s nothing obvious static to identify nationality: I find I can identify both Australian and American correctly at a rate considerably better than random, without ever having made a study of it.)
Can't we use our USA-centrism (centricity?) to make the behavior of the country drop-down just a little bit better? Surely I'm not the only one burdened with having to scroll past a hundred of these .. ahem.. OTHER... countries.. to find "United States of America".
Yes, I could begin typing "Unite.." but we all know that ends up on United Arab Emirates, and then when I continue on to "...d Sta..." and it doesn't work, only to find out this country picker uses "USA" or something similar so it breaks the autocomplete muscle memory.
Clearly, if we're the center of the known universe, we could use our power to make it a little easier to enter my billing and shipping information.
That just pisses off everyone else on the planet - plus the other countries in the Americas that consist of united states, and who equally consider themselves "American" much as French people are "European"
I know you're joking, but ideally forms like that should put the current country based on GeoIP at the top; these long selects really are kind of annoying: sometimes I accidentally use the keyboard to do weird shit because I accidentally didn't select the browser, some JS dropdowns don't allow typing at all, naming is somewhat inconsistent for some countries ("Netherlands" or "The Netherlands"?)
I'm only half joking! Yeah, I've found some put your GeoIP'd country at the top, which should be the default behavior. That throws me off occasionally, too, but I appreciate it!
Huh, but there is no 1 second gap between 23:59:59 and 00:00:00. The time is 23:59:59 for a whole second, and then once that second is done, the time is 00:00:00 the next day.
Thats why the day doesn't end at the instant of 23:59:59, nor does it end at 23:59:60 (if there is a leap second). It actually ends at 24:00:00. Which is the same instant in time as 00:00:00 of the following day. Every conforming implementation of ISO 8601 should know about that. And all software should conform to ISO 8601.
People seriously overestimate how many websites support Latin Extended-A to even be able to display ü or İ.
As someone whose last name contains a character from the same Unicode subset (ć), it's often a white square or just flat-out removed from my last name completely.
I think that's the point, people insist on using 23:59:59 as end of day instead of the correct 24:00:00 (which happens to be the same instant as 00:00:00 of the next day, since there's no gap between days)
My working theory on why this happens is that there are two different models and people sometimes have problem choosing the correct one.
When you say "Thursday" you mean entire 24h period. It is not a point in time, it is a label for a span of time.
But when you say "1 pm" you don't mean an entire hour, you mean a point in time that is more or less precisely 1pm.
It seems people extend the first model to a lot of cases where it is not correct. And so for many people their mental model of 23:59:59 is a label for a span of time that is one second in length.
If your model is that a day consists of 86400 "seconds", each second being a span of time of length of one second with a label like 12:37:28, then 23:59:59 is the last second of the day and 00:00:00 is the first second of the next day.
Working with spans is fraught with peril, though. It invites off-by-one errors.
If there's one person in the queue to the checkout, then span-wise, that person is the start of the queue and the end of the queue. But if the start and end are the same, what is the length of the queue?
(If you still insist it's one, you'll not be able to answer the question where the start and end of an empty queue is. There is no first or last person!)
```TSQL
select cast('2022-07-12 24:00:00' as datetime)
```
>>> The conversion of a varchar data type to a datetime data type resulted in an out-of-range value.
```python
from datetime import datetime
d: datetime = datetime(2022, 7, 12, 24, 0, 0)
```
>>> ValueError: hour must be in 0..23
No, it will not. Nobody gives a damn. Nobody will implement it.
I am still trying to get people to correctly denote beginning and end of a day (much more useful, practical). Everybody I work with seems to be bent on using 23:59:59 as the end of the day rather than start of next day. Explaining that there is no 1s delay between end of one day and start of the next isn't helping either.