|
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?
|
|
|
|
|
In my view heirarchical values like dates (or versions, or taxonomies etc) should be ordered in increasing or decreasing order, but never both.
So year -> month -> day or day -> month -> year but never, ever, ever month -> day -> year.
I don't think SQL is siding with anything other than a format that efficiently sorts. Not that SQL sorts dates based on a string representation...
cheers
Chris Maunder
|
|
|
|
|
S0, for July 3, 07/03 is okay by this standard, though 07/03/2022 would not be? Or 22/07/03 would work?
As you suggested, maybe numbers should never be used for months in scheduling, because changing decades-old conventions never ends in anything but confusion.
Jul3,22 | 3Jul,22 | 3Jul22 - none of these will end in confusion.
|
|
|
|
|
Yeah but the great thing with standards and conventions are that there are so many to choose from.
cheers
Chris Maunder
|
|
|
|
|
|
Looks like these days global hunger is not big of a problem anymore.
|
|
|
|
|
Julian dates all the way! 15-Jul-2022 = 2022-196 or 22196.
Julian Date Converter - Longpela Expertise[^]
I actually worked on an application back in the 90's where dates were tracked as Julian dates. Was a US Air Force transportation system and data records all had to fit in lines of 80 characters. Julian dates saved us one character. 
|
|
|
|
|
There is a large company I talk with regularly who shall remain unnamed who constantly refer to week numbers when talking dates. But not "week 1 = first week of January", but "week 1 = first week of their financial year". No one understands what they mean except them.
It's like a traffic accident. I just watch with my mouth agape.
cheers
Chris Maunder
|
|
|
|
|
yyyy-MM-dd for dates. But I don't run the USA, or even the world. ISO 8601
I've worked on systems where they've adopted (invented?) MM-dd-yyyy and MM-dd-yy.
Emphasis: using dashes, not slashes "MM/dd/yy", nor "dd/mm/YY".
I don't think those are used anywhere but in a legacy developer's fanciful invention. It's a nuisance for new work, and it's so baked-in that it's unlikely to ever be fixed.
Guaranteed to be incompatible with any country's format (ref Date format by country - Wikipedia[^]
|
|
|
|
|
I once had to present dates on an 80-character green screen terminal and chose 03Jul22 as the shortest but most understandable form to all countries.
|
|
|
|