NireBryce

reality is the battlefield

the first line goes in Cohost embeds

🐄 I am not embroiled in any legal battle
🐦 other than battles that are legal šŸŽ®

I speak to the universe and it speaks back, in it's own way.

mastodon

email: contact at breadthcharge dot net

I live on the northeast coast of the US.

'non-functional programmer'. 'far left'.

conceptual midwife.

https://cohost.org/NireBryce/post/4929459-here-s-my-five-minut

If you can see the "show contact info" dropdown below, I follow you. If you want me to, ask and I'll think about it.


gravity-pike
@gravity-pike

Every dev knows that working with dates and times sucks. Common knowledge holds that this is because dates are a human construct, and that devs make bad assumptions, like "there are 365 days in a year" or "there are 24 hours in a day" or "there are 60 seconds in each minute." And this is true! But it's also the case that devs have been done dirty by datetime libraries that don't let you be specific about what you're talking about.

Every time a Javascript date-picker returns a Date object, I die a little bit, because it's actually returning a date + time + timezone, and then it's left up to convention how to interpret this. Should the date be midnight in the local time zone? Should it be in UTC? Should it be at noon in the local time zone to maximize liklihood that the date portion will be the same in both local and UTC time zones? I've seen all three!

Java's time library fixes this. It follows the JSR 310 spec, largely based on the Joda-Time library which comprehensively lays out all of the different things that you might be talking about when you ask what time it is.


NireBryce
@NireBryce

you do not want to know how the Go datetime library works


srxl
@srxl

The layout string used by the Parse function and Format method shows by example how the reference time should be represented.

ok, what's the format

We stress that one must show how the reference time is formatted, not a time of the user's choosing.

wait. what

Thus each layout string is a representation of the time stamp, Jan 2 15:04:05 2006 MST

??????????? EXCUSE ME????????? what the fuck do you MEAN

An easy way to remember this value is that it holds, when presented in this order, the values: 1 2 3 4 5 6 -7

NO FUCK OFF!!!! that is fucked up!!!! that's not ok!!!!! why is the last one fucking NEGATIVE for no apparent reason???? WHY DOES IT HAVE TO BE THIS DATE WHAT THE FUCK ARE YOU ON!!!!!!!!! strftime is RIGHT FUCKING THERE why are you reinventing the wheel IN THE MOST BATSHIT UNHINGED WAY POSSIBLE fuck off!!!!!!!!!!! how does anyone take this language seriously????????

There are some wrinkles illustrated below.

yeah, i fuckin bet.


You must log in to comment.

in reply to @gravity-pike's post:

A datetime.datetime can be either timezone-aware or naive, but (to me) it's mind-bogglingly obtuse when this will be the case. For example, datetime.utcnow() returns a naive datetime, despite having the timezone in the name, and despite datetime.now() being a distinct function.

Furthermore, timezone naive objects seem to have a 50% chance of not working when you try to do timezone-dependent logic on them (this is what I want to see), and a 50% chance of just pretending that they actually are timezone-aware, and that timezone is whatever the machine's local timezone is. (For a timezone-aware datetime, .astimezone() will change it so that it represents the same instant in the new timezone. For a timezone-naive datetime, the same function will convert it to a timezone-aware datetime in the local timezone before doing the same transformation.)

Both of these combine so that datetime.utcnow() returns a datetime which is neither in the utc zone, nor is it now. >:(

Rust’s chrono is basically this good! It doesn’t have a ā€œperiodā€ type (which is an unfortunate omission for scheduling) and the IANA time zones come from a second package (but are still fully integrated with the base library).

in reply to @srxl's post: