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.

[–] [email protected] 2 points 11 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 2 points 11 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 1 points 11 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.

[–] [email protected] 2 points 11 months ago (1 children)

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

[–] v9CYKjLeia10dZpz88iU 0 points 11 months ago* (last edited 11 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.