|
Where's that?
Here in the UK, road sign distances are in miles and speed limits are in MPH.
|
|
|
|
|
We were in the process of converting to metric but couldn't figure out how to handle 19" racks. 
>64
Some days the dragon wins. Suck it up.
|
|
|
|
|
To correct your misunderstanding of the US, we do (and have) used both English and metric. I, like other kids of my generation, learned both in high school back in the 1960s. And I was raised in a small town/rural area. Americans really have no issue using both and switching between them.
|
|
|
|
|
Actually, it all depends on what of the country you look at. I have lived and worked in the US, and have experienced this for myself.
While I agree that the Metric system is taught (to some degree, again depending in what state yih are in), I have yet to see road signs in anything other than Miles or MPH. Or fluid measures - especially when the US usesUS gallons VS. Imperial gallons. Or weights. And so on.
This isn't to say that metric measures aren't used in the US. At least in the scientific community they have embraced the Metric system as it is provides a consistent base with the rest if the scientific community. But as far as the average daily usage in America, I have yet to see it take hold.
I am not looking to start a flame war with this. This is simply my own experiences and observations.
I also admit that there are still some holdback's to the English system - specifically we still use acres instead of hectares. That would be more difficult to change and use as it would impact how to describe land usage (a fraction of a hectare vs. one acre). But for the most part we here in Canada have made the switch back in the 70s, and have pretty much given up on the English system with no regrets.
|
|
|
|
|
Back to the Stone Age! Fred Flintstones units forever! LOL
|
|
|
|
|
In comments, I have long used yyyy-MMM-dd format (e.g. 2022-Jul-14). When dating documents, I use dd-MMM-yyyy (e.g. 14-Jul-2022). When storing dates (e.g. in a database) I store UT, converting from the current time zone when necessary. When displaying dates in a program, I use the current locale, converting from UT to the local time zone.
This doesn't solve all issues - conversion between time zones can be problematic, but is "good enough" for most of my needs.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
For Chris Maunder:
And now for something completely different (Monty Python).
Are there any rules or restraints to posting code (C code) we have written? It's pretty short maybe 3 routines.
I am the author of code but make references to the inspiration for it (all in the comments).
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
jmaida wrote: Are there any rules or restraints to posting code
If it's yours, if you have the right to post it, if you feel it will be of value to someone, somewhere, then go for it!
If it's small and is just a "here's how to do x' then maybe post it as a Tip rather than an Article (though either is fine)
cheers
Chris Maunder
|
|
|
|
|
I think I will look at your articles and tips format.
Need to do a bit of research again on topic.
It's been awhile.
Thanx
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Easiest answer: move to the states! (Now might not be a good time, though.)
|
|
|
|
|
Or leave the US (either solution works...  )
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
|
Darn, and I wanted to use 1656806400000 
|
|
|
|
|
I was under the impression that epoch dates were unambiguous until I came across those that weren't.
Apparently there are so many different versions of those too 
Epoch (computing) - Wikipedia
On a side note, "rationale for selection" on that page is blank for Unix epoch. I guess someone just pulled that year out of you-know-where 
|
|
|
|
|
Yes - I was bitten by that the other week. Garmin, for example, bases its epoch on the day the company was born.
I'm not saying they have a alightly skewed notion of their importance in the universe or anything, but...
cheers
Chris Maunder
|
|
|
|
|
As I've said elsewhere hereabouts - in over 40 years of writing software, the handling of dates has been the biggest single problem I have had to tackle. It's staggering that after all these years, date handling is still a (mostly lost, incorrect and misunderstood) black art to almost all software systems, including date handling libraries, developer frameworks and just about every piece of end user software and web page you come across.
8(
|
|
|
|
|
What about the war between point and comma as decimal/thousand separator?
A joke comparing to dates war, but...
|
|
|
|
|
We just collect month, day, and year as separate data values and assemble them in processing, but that's mostly birth dates, so the calendar inputs are mostly an aggravation instead of a convenience. Another simple solution would be to make an onchange that adds a note containing the long-form of the entered date, or force the use of the calendar input.
|
|
|
|
|
Feel your pain with AWS. We have to set the culture code at the start of every Lambda we have because our main website sends dates in the british dd/mm/yyyy format and lambdas default to US format regardless of the region. The first 2 weeks of January where fun!
I'm blaming AWS but to be honest it's probably the Linux image they use to spin up the lambda. But I don't want to blame Linux. Stupid AWS
|
|
|
|
|
RooN3y wrote: But I don't want to blame Linux. Stupid AWS
cheers
Chris Maunder
|
|
|
|
|
|
That's the tip of the iceberg.
When you start getting to points in time and calculating between different points in time it becomes even more of a pain - then some developer decided to save dates without a timezone because "why would anyone ever need to know the timezone?"
Dates are perhaps one of the biggest PITAs in data.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Our dirty secret is we store times as local timezone and we've had an outstanding TODO from about 14 years ago to convert all of them to UTC. Generally pretty easy - just add 5hrs. Except we have to take into account daylight saving. For every year. And then you have to be careful about the boundary times and the order in which you update. And then your head hurts and you look at the other things on your TODO and think "dates work. Let's not stir the hornets' nest"
cheers
Chris Maunder
|
|
|
|
|
Absolutely, I agree. I alwys use '2022-07-03' OR '2022/07/03'. Different separator, same meaning.
|
|
|
|
|
American here. I agree that we need to resolve this date issue to something unambiguous, but I have a question:
Quote: 2022-07-03 is universal. Everyone gets that, even SQL.
... which is yyyy-mm-dd, right? Could/should we say that SQL is siding with the US on this one? I mean ... everyone adapts nicely to SQL dates, right?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
