PowerShell is older than I realised
-
-
I'm looking forward for the next article in the series.
I hear they are pushing to get it out within the next 4 years.
-
If your date parser throws an exception and/or errors out, don't just assume everything was hunky-dory and store the Date's default value (1970-01-01 00:00:00 UTC).
-
But .NET uses 0001-01-01 00:00:00 as the default ...
-
Right, but that's not the date being used here, is it?
C's
time_t
has 0 stand for the date I mentioned in my previous post. For that matter, any language that uses UNIX/POSIX timestamps does that.
-
Right, but that's not the date being used here, is it?E_SENSE_OF_HUMOUR_NOT_FOUND
Filed under: FTFY
-
And SQL Server uses 1900-01-01 00:00:00 as the default.
Because consistency is important!
-
-
Because consistency is important!
They're all bullshit dates that should've never be used, so who cares if they're consistent?
-
-
Don't forget 1601-01-01
-
What uses that as the default?
-
Didn't bother with the link, but every time I try to do something in powershell, it's a fucking battle for hours. And then I do it in actual C# in 5 minutes.
-
Windows' FILETIME structure (Which is used for the system time in winapi)
-
and of c
Don't forget 1601-01-01
ourse there is 1899-12-31
.... though i forget which database uses that as their epoch. i do remember why they use it though! there was a bug in the first version which tagged 1900 as a leap year (it isn't)
-
Honestly, we should all just agree that the default date should be
2001-09-11
0001-01-01 BC
(not to be confused with0001-01-01 AD
)
-
1899-12-31
Access, apparently, to maintain compativility with
i do remember why they use it though! there was a bug in the first version which tagged 1900 as a leap year
Lotus 1-2-3
-
-
yeah, I edited as I dug deeper into why access had that date originally.
-
This is why NULLs ARE a good thing.
-
Microsoft's philosophy is to allow time to go back until before the Gregorian Calendar can be assumed. SQL Server interprets that as January 1, 1753. I'm sure back in the day someone on the Windows team determined that to be January 1, 1601. (The Gregorian Calendar was introduced in 1582, but adoption was slow. SQL Server's date is the first start of a year after the British Empire adopted it.)
-
And you can run C# code from powershell ...
-
Access used 1899-12-30 instead
The software I'm working on uses that in some places, despite being written in VB.net. I wonder if v1 was an Access application?
-
Or pre-.NET VB, or it had to interoperate with Access, Excel, or pre-.NET VB, or it used OLE DB rather than RDO or ADO, or it used an ActiveX control. One of the seven.
-
Code comments suggest it's compatibility with SQL "empty dates". Which is weird since the DB engine is MSSQL
-
-
Obviously the default date should be January 1st, 4713 BC. After all it's not rocket science (otherwise it would be (November 17, 1858).
I do realize the former may lead to numbers so large that some might consider them astronomical.
-
Honestly, we should all just agree that the default date should be 2001-09-11 0001-01-01 BC (not to be confused with 0001-01-01 AD)
Julian or Gregorian?
-
I don't think Yami is from Belgium
-
-
@RevCurtisP said in PowerShell is older than I realised:
Obviously the default date should be January 1st, 4713 BC.
The Julian Day number system is the way of doing date calculations as it avoids a vast number of politically-imposed complexities.
http://aa.usno.navy.mil/data/docs/JulianDate.php
-
It's all a symptom of badly constructed type systems.
A decently constructed type system consists of entirely orthogonal types, and each type should have (potentially many instances of) typed
NOT_VALID
, all of which, in themselves, should be orthogonal to each other and the untypedNO_VALUE
.So, assuming we have need for a
DateTime
andBoolean
types, the following holds:| 12-12-1900 | 00-00-0000 | NO_VALUE | #t | is_date_time? | Y | Y | N | N | is_bool? | N | N | N | Y | is_valid? | Y | N | N | Y |
-
@LB_ Go uses 0001-01-01T00:00:00Z
-
@ben_lubar really? i would have expected Go to be y10k compliant which would mean it's capable of representing dates arbitrarily far into the past and future
-
@accalia it can represent dates from about 200 billion BCE to 200 million AD.
-
@No_1 Erik Meijer, the Haskell compiler writer and researcher, wrote "Monad", the language that would eventually be branded PowerShell, before 2002.
-
@RevCurtisP said in PowerShell is older than I realised:
Obviously the default date should be January 1st, 4713 BC.
But that's a nonsense date. It's been firmly established that the world began on October 23rd1, 4004 BC.
At 09:00:00.
1 Which by sheer absolute coincidence happens to be Weird Al Yankovic's birthday. And my father's.
-
Dates should start on September 4th 1752
-
@da-Doctah said in PowerShell is older than I realised:
@RevCurtisP said in PowerShell is older than I realised:
Obviously the default date should be January 1st, 4713 BC.
But that's a nonsense date. It's been firmly established that the world began on October 23rd1, 4004 BC.
Recognizing those numbers I expect your source was Good Omens, which gets several key details wrong, including the time, which was actually at noon.
-
@powerlord and 2016-1970 is 46, the time reported in OP