As a Real Programmer(tm) I have developed such a deep fear of anything time and date related that I would fully endorse dispatching an API call to the tz_database instead of attempting any fucking part of this.

Kids, it's fine to meme about silly stuff... but date and time is deadly serious, regardless of how careful you think you're being you are wrong.

Do you know how many timezones there are in Indiana? No? Look it up and scream in horror.

[–] sunbeam60@lemmy.one 26 points 7 months ago

What if I told you that weekend days are locale dependent?!

Time and date is the black hole where optimistic programmers go to die. Nothing is simply with localisation and if you think it is, you mustn’t have worked enough with it.

Source: Run a system that schedules millions of interactions across the world and deeply depend on this. The amount of code to manage and/or call out to external services to give us information about time zones, summer time, locale specific settings, day names, calendar systems, week numbers etc etc.

[–] AndyLikesCandy@reddthat.com 8 points 7 months ago

Here's a fun thought experiment: What gregorian year and date will the spacian date value of zero correlate to? Trick question.

The atomic clock on the moon and every other celestial body colonized will simply start at zero, and thanks to relativity it will not actually be the same rate of time passing as on earth.

Enjoy your nightmares.

[–] coloredgrayscale@programming.dev 7 points 7 months ago (1 children)

Luckily we won't colonize the moon or another planet anytime soon...

[–] kogasa@programming.dev 4 points 7 months ago* (last edited 7 months ago) (1 children)

IMO every datetime should be in utc, and variables for datetimes should either be suffixed "Utc" or have a type indicating their time zone (DateTimeOffset or UtcDateTime etc). Conversion to local time happens at the last possible second (e.g. in the view model or an outbound http request parameter). Of course that doesn't solve the problem of interoperating with other ~~morons~~ programmers who don't follow these rules, but it keeps things a lot neater locally.

Scheduling based on regional time conventions (holidays, weekends, etc) is just not great though.

[–] usrtrv@lemmy.ml 2 points 7 months ago (2 children)

Throwing UTC everywhere doesn't solve comparisons around leap seconds. I'm sure they're other issues with this method, but this is kinda the point of "just use a library". Then it's someone else's problem.

[–] kogasa@programming.dev 2 points 7 months ago

I'm a .NET dev, I don't have a concept of "just use a library." Everything is a library. I don't mean "using int for datetimes is ok as long as you label it utc," I just mean "don't deal with time zones."

[–] v9CYKjLeia10dZpz88iU@programming.dev 1 points 7 months ago (1 children)

Unix is the easiest format I’ve used. It’s easy to parse, it’s consistent, there’s not usually competing unix like formats, it converts perfectly to other time formats, most file explorers can immediately sort it correctly, and it’s clearly the date from which the universe spawned into existence.

[–] xmunk@sh.itjust.works 2 points 7 months ago (1 children)

It's alright, but real programmers use Julian UTC.

[–] v9CYKjLeia10dZpz88iU@programming.dev 0 points 7 months ago* (last edited 7 months ago)

I also really like the Bitcoin block number. It will likely be one of the most provable records of time passing, but not as convienent for tracking or converting time.

[–] DAMunzy@lemmy.dbzer0.com 3 points 7 months ago (1 children)

2 timezones but the complication is that it is dependent on which country you're in?

[–] xmunk@sh.itjust.works 4 points 7 months ago

There are two distinct time offsets used in Indiana but there are 11 different timezones https://en.m.wikipedia.org/wiki/Time_in_Indiana

[–] Zanothis@lemm.ee 1 points 7 months ago* (last edited 7 months ago)

Relevant talk by Jon Skeet

https://invidious.io.lol/watch?v=64X8rCy1jSA