triallax changed the topic of #numbat to: The Official Numbat channel | This channel is publicly logged at | Please read if you're new to IRC!
achin has quit [*.net *.split]
ChanServ has quit [*.net *.split]
triallax has quit [*.net *.split]
joaj has quit [*.net *.split]
joaj has joined #numbat
triallax has joined #numbat
ChanServ has joined #numbat
achin has joined #numbat
joaj has quit [*.net *.split]
joaj has joined #numbat
triallax has quit [Write error: Connection reset by peer]
triallax has joined #numbat
sharkdp has joined #numbat
sharkdp has quit [Remote host closed the connection]
triallax has quit [Remote host closed the connection]
triallax has joined #numbat
triallax has quit [Remote host closed the connection]
triallax has joined #numbat
sharkdp has joined #numbat
<sharkdp> The new datetime handling is so useful, I'm wondering if we should make 'now' a keyword.. so we can type 'now + 44 hours' instead of 'now() + 44 hours'?
sharkdp has quit [Remote host closed the connection]
sharkdp has joined #numbat
<achin> is that just to save typing a few characters? or to somehow indicate that there is something special about getting the current time?
sharkdp has quit [Remote host closed the connection]
sharkdp has joined #numbat
<achin> if someone defined a function like fn yesterday() -> DateTime = now - 25 hours, would it feel strange to use parens for `yesterday()` but no parens for `now` ?
<sharkdp> no, you're right. lets not introduce a keyword for it
<achin> i didn't quite understand your comment about removing `Constant::DateTime`, since i think it's used (for example, in
<achin> i do confirm that i can remove ast::Expression::DateTime, but i think i still need typed_ast::Expression::DateTime
<achin> ahhh, no, i do not. ok, removing that too 👍
<achin> thank you for that good observation!
<sharkdp> I wouldn't have spotted that either.. but when you said you didn't find a codepath to trigger the pretty-printing of that AST element, that was suspicious :-)
<sharkdp> achin: Is there any way we can *enter* datetimes by using a timezone (as opposed to a offset)? For example, I might want to convert a given time in US/Mountain to my local timezone
<achin> sharkdp: yes, but it's a bit clunky:
<achin> parse_datetime("2024-02-08T11:34:00-07:00") -> "local"
<achin> or: parse_datetime("Thu, 8 Feb 2024 11:34:00 -0700") (those are the only two accepted formats at the moment)
sharkdp has quit [Remote host closed the connection]
sharkdp has joined #numbat
<sharkdp> Using offsets, yes. But I can't specify timezones, right?
<sharkdp> I wrote down a few things that came to my head when reviewing your PR and playing with datetime handling. Feel free to add new items and/or discuss existing ones:
<achin> by name? no i don't think so
<achin> with a future version of `parse_datetime` that can accept a custom formatting string, it looks like you can use an abbreviation like "CST" instead of the numeric offset. i don't think a name like "US/Mountain" would work there, but it would be easy to test it and try
<achin> several of your suggestions involve customization based on personal preferences, so i think we can extend the config file with things like the users favorite date formatting string
<achin> or perfered default timezone (today it's local, but maybe someone prefers UTC)
<sharkdp> yes, right
<triallax> fwiw linux users should just be able to set the TZ environment variable
<achin> good thought!
<triallax> but i have no idea if other systems have an analogous envvar
<achin> sharkdp: this datetime PR has accumulated a lot of commits, so please let me know if you'd like me to squash them down into a fewer number of commits
<sharkdp> I'm okay with leaving it as is
<sharkdp> One thing I'm still not sure about is this behavior:
<sharkdp> I'm comparing Numbat with Frink. Both results can be argued to be correct. But I think I like the Frink result better.
<sharkdp> I don't want to see a datetime that is set in summer being rendered in the "local" time (where it is currently winter)
<triallax> i feel rather strongly that frink is the correct one here
<sharkdp> I think I want "local" to mean "Europe/Berlin" (which switches UTC offset based on the date), instead of "Europe/Berlin with the UTC offset that is correct *now*"
<triallax> yeah, exactly
<achin> ahhh, this is a tricky one
<achin> made even more tricky by my general distaste for DST :)
<achin> frink's behavior is reasonable, because it's more accurately conveying that this point in time is going to "feel like 2AM" instead of 1AM. but i think i still might be confused by it if i wasn't paying attention
<triallax> i have conflicting feeling about dst as well, but it exists :)
<sharkdp> I was trying to look into it, but I'm not sure how we would even implement this using chrono/chrono_tz?
<triallax> also, this is troublesome regardless of dst
<triallax> think e.g. timezone changes
<triallax> dst isn't the only reason a timezone can change utc offsets after all
<sharkdp> I mean, all of that is handled correctly. I think the question here is: should 'datetime -> "local"' show the date and time with the *current* UTC offset, or with the UTC offset *that my current timezone was at at the specific instant in time represented by the datetime object*.
<triallax> i'd strongly prefer the latter if feasible
<triallax> i haven't looked into it but it's not surprising if there's no good way to do it
<sharkdp> why?
<triallax> if chrono doesn't have a way to deal with timezones
<triallax> but like i said i haven't looked into it
* triallax goes and builds the datetime branch
<triallax> btw i don't know when i'll get around to the extended formatting pr, i'm probably going to get quite busy the next couple weeks
<triallax> okay, so `now() + year` works but `year + now()` doesn't
<triallax> is this intentional
<achin> yeah. i recognize this breaks the commutative property of addition, but in my head "1 year + now()" doesn't make that much sense
<triallax> i get that
<triallax> it does break it but i wouldn't say it's that important
<sharkdp> Wow, why is this such a rare use-case (displaying a datetime with the UTC offset of my timezone *at that specific instant in time*)? I can't even find someone having the same problem :-)
<triallax> do you have any use cases in mind?
<sharkdp> The one from the image above. I would really like the Frink behavior (unless someone convices me otherwise).
<triallax> i thought you were talking about numbat's current behavior
<triallax> i agree that frink's behavior would be really nice
<triallax> i know that it's possible in theory, but it depends on the api we're using probabl
<sharkdp> I mean, chrono/chrono_tz have all of the timezone handling. But 'Local' seems to refer to the current UTC offset, not to the current timezone
<sharkdp> And I don't see a way to retrieve it
<triallax> yeah, that's the problem i was fearing
<triallax> there's, but it hasn't gotten a response
<triallax> also checked and setting TZ works :)
<triallax> triallax@satoru ~/D/r/numbat (datetimes)> TZ=Asia/Tokyo ./target/debug/numbat -e 'now()'
<triallax> Fri, 9 Feb 2024 05:50:24 +0900
<triallax> the timezone completion is _really_ nice
<triallax> hmm does this use the system tzdata database or does it bring along its own
<achin> it bundles in its own tzdata via
<triallax> is it possible to use the one provided by the system at runtime or something like that?
<triallax> couldn't find any feature flags for this in chrono-tz so i'm thinking not
<achin> i don't know, i'd have to do some research
<sharkdp> Ah, I also just found - it seems it's not possible to get the current timezone at the moment.
<triallax> the comments on this one have some useful workarounds
<triallax> i can also research more online, because i wouldn't trust one random github comment :)
<triallax> oh, also one of the comments mentions a package
<achin> but we don't want the *current* timezone, we want the timezone that would normally be used at some arbitrary point in time
<triallax> achin: that's confusing me
<sharkdp> I think it's exactly what we want
<triallax> e.g. Europe/London is an overarching timezone for both summer time and winter time
<sharkdp> yes
<triallax> so i don't see where the problem is
<achin> oh, hmm
<triallax> sharkdp: yeah, seems simple enough to use too
<sharkdp> achin: chrono only gives us UTC-1 or UTC-2, based on the current time of the year. But this iana-time-zone crate can give us "Europe/Berlin", which includes all the information about when which UTC offset is used
<achin> how will `let tz: chrono_tz::Tz = "Europe/London".parse()?` be parsed? will it depened on the current date?
<triallax> shouldn't be relevant i think
<triallax> a timezone is independent of the current date
<triallax> but when "resolved" for a given date you can then get the specific utc offset for that date
<achin> ok, i see. there's an distinction here between "offset of the current timezone" and "current timezone"
<triallax> (i'm speaking generally how it should be, i have no idea how chrono works)
<sharkdp> chrono works in the same way as triallax explained, yes
<achin> while the offset of the current timezone changes twice a year, the current timezone doesn't change
<triallax> exactly, yes
<achin> ok, got it
<triallax> i mean, actually that's not entirely true
<triallax> there's CEST and CET for instance
<triallax> but do we have those broad timezones?
<triallax> if it's only stuff like Europe/London or Asia/Tokyo then should be fine
<sharkdp> But CEST and CET are not timezones, I think
<sharkdp> those are "clock times"
<triallax> i thought so, but many people seem to treat them as ones :D
<triallax> but yeah you're right
<sharkdp> In Europe/Berlin, we have CET in winter and CEST in summer
<triallax> indeed
<achin> well, i ran the "get_timezone" example from the iana-time-zone crate, and it correctly returned "US/Eastern", so that's a good sign :)
<sharkdp> I only learned about most of this yesterday... after reading this: :-)
<triallax> i was forced to learn it after grappling to death with flutter and dart's horrible timezone handling
<triallax> chrono seems a lot saner
<triallax> i'm still traumatised :(
<achin> if only swatch internet time actually became a thing
<triallax> til about swatch internet time
<triallax> okay maybe i'm half-kidding, but does chrono have martian time
<triallax> chrono-tz*
<triallax> btw the tom scott video on datetimes is a must watch:
* achin adds to his to-watch queue
<triallax> it's informational of course but i can never resist watching tom descend into madness while explaining his datetime adventures
<sharkdp> achin: I just implemented a function called 'human', entirely in Numbat, based on DateTime support:
<triallax> that's so cool!
<achin> very cool!
<triallax> this is tangential and debatable, but is there a good reason to prettify // to plain function calls
<sharkdp> '//' is basically syntactic sugar. and that is gone after the parser. in the AST, we do not distinguish between 'f(x)' and 'x // f'. we *could* do that, of course.
<triallax> from the perspective of the user i think keeping // might be desirable, but i'm not sure
<sharkdp> in general, we do not aim to pretty-print the exact input of the user (that would not be very helpful), but rather something that is ... unambiguous? or "more unambiguous"
<achin> i kind of view the function syntax as "canonical", so i don't mind seeing it in function call form
<triallax> fair
<sharkdp> For something like '100 + 44 // sqrt', I think it's nice to see that pretty-printed as 'sqrt(100 + 44)'. For these 'human' examples above, it's not very useful.. or even slightly confusing, I agree.
<triallax> i'm thinking more about the instances where using // is explicitly desirable
<triallax> say, 1 K // to_celsius
<triallax> both are entirely the same of course, but the name of the function makes it more readable called postfix
<triallax> but yeah, there isn't an easy way to solve this, i wouldn't want // sqrt to be pretty-printed as-is
<sharkdp> Right. We could absolutely special-case it for some functions. Might help users learn about //
<triallax> that's an option
<triallax> i could open a ticket for this
sharkdp has quit [Remote host closed the connection]