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 bytecode_interpreter.rs)
<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>
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: https://github.com/sharkdp/numbat/issues/323
<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 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
<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 :)
<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: https://i.imgur.com/4RYMmaT.png
<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]