Ok, everyone who’s ever had to use datetime hates it, but not because it’s insufficient, but because international date/time is such a nightmare that the library must be complicated enough to support all the edge cases I’m convinced that library has a function for traveling trough time.
For years I’ve wrapped datetime with custom functions that do exactly and only what I want to mitigate its all-plumbing-zero-porcelain approach to the problem.
Ok, everyone who’s ever had to use datetime hates it, but not because it’s insufficient, but because international date/time is such a nightmare that the library must be complicated enough to support all the edge cases I’m convinced that library has a function for traveling trough time.
For years I’ve wrapped datetime with custom functions that do exactly and only what I want to mitigate its all-plumbing-zero-porcelain approach to the problem.
Obligatory Tom Scott video
This is exactly why I love PowerShell.
Need the [DateTime] object from 10 years ago? No biggie, just chuck
(Get-Date).AddYears(-10)
down your console.Need it in a specific timezone? That one’s trickier, but since PowerShell can do .Net, run this:
And you get a DateTimeOffset object, which is this beauty:
DateTime
is the time in your target timezone,UtcDateTime
is, well, the UTC time, andLocalDateTime
is the time on host you ran the commands on.Complicated or not, the interfaces suck. And dont have to. And that’s the problem.
exactly why I wrap the parts I need, it’s like git, tons of power, zero help.