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.
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.
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.