01:13 wayland76 left 01:19 kylese left, hulk joined
arkiuat oh, but if that is the .WHICH then the same time in different timezones isn't going to match 01:30
I'd have though the .WHICH would be normalized to UT or something
01:36 wayland76 joined 01:58 deoac left 02:13 Aedil joined 02:15 hulk left, kylese joined
guifa not having seen all the background convo, two value type objcts with the same WHICH can be considered identical 02:52
but two datetimes with different offsets aren't quite identical 02:53
I get that they "feel" the same since they reference the same point in time, but for the WHICH to be the same, we'd expect all method calls to produce identical results 02:59
Voldenet it makes me a bit annoyed that "timezone" and "offset" are the same 03:07
I mean, you can't do this: 03:09
m: DateTime.new(2025,8,8,14,23,0,timezone => "Europe/Berlin").say
camelia This type cannot unbox to a native integer: P6opaque, Failure
in block <unit> at <tmp> line 1
Voldenet except timezone depends on both date and offset 03:10
m: say DateTime.new(2025,8,8,20,23,0) eqv DateTime.new(2025,8,8,14,23,0,timezone => -6*60*60)
camelia True
Voldenet it's a very annoying problem 03:11
(also, the above shouldn't be true, as it holds different data) 03:12
m: say DateTime.new(2025,8,8,14,23,0,timezone => -6*60*60)
camelia 2025-08-08T14:23:00-06:00
Voldenet m: say DateTime.new(2025,8,8,20,23,0) == DateTime.new(2025,8,8,14,23,0,timezone => -6*60*60) 03:15
camelia True
Voldenet I think that numeric equality should return the same value (since it casts things to timestamps) and eqv shouldn't 03:16
and back to timezones, maybe `offset` argument should exist (accepting only int) and `timezone` should also accept String tz identifier 03:17
03:18 stanrifkin joined 03:21 stanrifkin_ left
Voldenet otoh I hate timezones, it's what happens when you take backward compatibility too seriously 03:21
04:26 oodani left 04:27 oodani joined, oodani left 04:28 oodani joined 04:50 kylese left 04:51 kylese joined 05:31 stanrifkin left 05:53 arkiuat left 06:04 arkiuat joined 06:09 arkiuat left 06:20 arkiuat joined 06:25 arkiuat left 06:38 arkiuat joined 06:43 arkiuat left 06:47 arkiuat joined 06:51 melezhik joined 06:52 arkiuat left 07:03 Sgeo left 07:23 arkiuat joined 07:27 arkiuat left 07:37 wayland joined 07:38 wayland76 left 07:48 arkiuat joined 07:52 arkiuat left 08:13 kylese left 08:15 kylese joined 08:20 apa_c joined 08:22 arkiuat joined 08:26 arkiuat left 08:49 arkiuat joined 08:53 arkiuat left 09:00 melezhik left 09:21 arkiuat joined 09:26 arkiuat left 09:46 arkiuat joined 09:50 arkiuat left 10:12 Aedil left 10:19 arkiuat joined 10:23 arkiuat left 10:28 Aedil joined
lizmat Voldenet: there's quite a lot of work needed to support named timezones, guifa knows all about that 10:37
also: politics can decided to change timezone logic on a whim, so having that in core feels not flexible enough 10:38
10:44 lichtkind joined 10:53 arkiuat joined 10:57 arkiuat left 11:20 arkiuat joined 11:26 arkiuat left 11:35 arkiuat joined 11:42 soverysour joined, soverysour left, soverysour joined 11:43 soverysour left 11:48 soverysour joined, soverysour left, soverysour joined 11:56 soverysour left
arkiuat ah yeah, you're right. Numeric equality is the right test for "same time," not === as I had implied above 12:16
I agree that named timezones need their own dedicated module for those who need it, and shouldn't be part of DateTime 12:18
12:29 soverysour joined, soverysour left, soverysour joined
guifa that's why you have DateTime::Timezones :) 12:30
the trick is though that if you update it, there's no easy way to update modules that `use` it 12:31
arkiuat timezones are like leap seconds: if you really care, then you'll have your code pull the latest version before making any definite assertions 12:32
guifa Yes, but what I'm getting at is more that when Raku compiles with a module, that module is locked in at that version 12:34
arkiuat I wonder how much code out there thinks that the last-ever leap second was at the end of 2016
right, so the TZ data should be in a database, not hardcoded
guifa Which it is... but how does the module update itself? 12:35
if you upgrade the module, anything already compiled will still use the old version of the module 12:36
arkiuat I don't see that it would need to if it's polling an online database for the timezone data. If it's not hardcoded, it's not compiled.
guifa it's not practical to pull down 450k (and then adds dependencies for downloading and processing the files) 12:37
arkiuat Timezones are not practical, I agree. 12:38
but anything hardcoded is going to have the problems that you're pointing out to me.
Besides, you shouldn't have to pull all 450K, just make a query for the bits and pieces that you need. 12:39
guifa I mean, if I wanted to create a whole tz server, sure. The tz database isn't a database as a relational db. It's more like source code that needs to be compiled and one tz can reference another tz 12:43
then you'd still have the question of which timezones to download and when 12:45
arkiuat yeah, well, that's not the right way to do it, unless you want to subject yourself to the whims of the various local legislatures around the world
if any of them changes, then you have the update propagation problem that you're pointing out
you can either live with that, or find someone who is running an efficent and updated online timezone database that responds efficiently to selective queries. I don't really see the third alternative 12:47
12:48 soverysour left
arkiuat it's one reason why i've never bothered with the database that you're referring to 12:50
disbot4 <jubilatious1_98524> How often are timezones updated? Are you suggesting developers cannot/shouldn't handle EST <-> EDT themselves? 13:02
arkiuat that'll work fine until DST is abolished, or made permanent again for a little while the way it was back in the 1970s 13:04
13:09 apa_c left
guifa jubilatious: they should not handle it themselves 13:18
you also haev to figure that if you're going to do historical dates correctly, you need more specificity than just EST/EDT 13:19
Consider in the US if a state changed timezones or decided to stop recognizing DST.
In the tz database, it then splits off and becomes an entirely new timezone. then there's a separate database that correlates that the more common parlance EST/EDT 13:20
arkiuat yeah, if you have to deal with historical timezones more than just a few years back, that's a whole nother can of worms 13:22
but at least that data can safely be hardcoded!
guifa That's why when you choose a timezone, you choose cities 13:23
The theory behind the tz database was that political borders, etc, are more volatile, but cities are a bit less subject to change. 13:24
jubilatious: the tz database is updated a few times a year. Most changes are given with tons of advance notice ("We'll stop following DST in the year 2027") so they don't rush to push out an update but wait until a few have been collected 13:25
Sometimes they'll push out a change almost immediately because some country will suddenly decide a day before to not observe DST 13:26
tends to be ultimately anywhere between 3-5 a year, but with some years being below and some well above that
On a regular OS, you just call the OS -level functions and make the assumption the OS is updated (generally but not always safe assumption) 13:39
I could make a Raku module that does that via native call, but then it's not universal if there's not support for a given version/os,etc. The pure Raku one is nice because it'll work no matter where you use Raku. But Raku isn't really designed for dynamically linking modules (there are ways, but those bypass the security / functionality safety net with which module system was designed) 13:41
13:45 soverysour joined 13:47 arkiuat left 13:59 arkiuat joined 14:04 arkiuat left
ugexe if i was using a module that updated itself at runtime i probably would not use it anymore 14:16
especially if it did so using the network
14:22 soverysour left 14:32 arkiuat joined
guifa there could be some uses cases but i aim for the unix principle of having them do one thing and do it well, but made to work together 14:33
unless it's a explicitly network module, checking for updates with the network feels....outside that scope
14:37 arkiuat left
ugexe my hunch is it is actually problematic 14:54
for example if some module is updated to account for new time zones but other parts of that system (such as the OS) are not, then it could lead to issues 14:55
further the is the more general issue of inconsistency in behavior for the update itself. what happens when it fails, doesn't have write access to the storage etc. the behavior of the program can thus change based on theses and may not be deterministic 14:56
it is comparatively more easier to reason about regularly updating dependencies, particularly if just a subset of time sensitive ones 14:58
i do concede that neither solution is perfect though
guifa I know that there's no way for zef to fully know the dependency chain for modules, but do you think there might be a way for it to eventually handle autoupdating of fully declared (in META6) dependencies. Like if someone said `zef upgrade foo` that it then offers to recompile modules that used older versions that would (based on the :ver<>) prefer the newer? 15:01
15:06 tgt joined 15:07 tgt left, arkiuat joined
ugexe given people should be pinning their dependencies *in their code* as well as their META6 data, i don't see how that would be very useful 15:07
guifa oh yeah, I'm just thinking as a helpful trigger to say "it looks like you may want to recompile these modules" (and offer to do it) and then a message "there may be others, and some modules may not use the new one even after recompilation depending on their version requirements", to avoid anyone thinking it definitive. 15:11
15:12 arkiuat left
ugexe that is a really dev specific thing though. you'd never do that on a production system. and its also bad in that you don't know the tests for any of those things work after making such changes 15:17
if something like that were to be accomplishable in zef it'd need to be via multiple commands, and each of those commands would need to have a good reason to exist on their own. as an overly naive example: `zef depends IO::Socket::SSL | zef upgrade -` 15:21
that obviously doesn't work because it doesn't recompile the existing stuff, but if there was a good reason for a zef command to be able to tell rakudo to recompile something then that would be another piece that could be used for this specific ask 15:22
guifa actually I forgot that depends is a command
Voldenet wow, DateTime::Timezones is awesome, you just import the right module and suddenly it works as I'd expect 15:27
`class DateTime is DateTime` and I didn't know this was legal :O 15:28
guifa Voldenet I didn't either :-) But lizmat++ pointed it out to me 15:29
15:29 arkiuat joined
Voldenet and it's a lot better than augment which wrecks the original class 15:33
15:33 arkiuat left
guifa also along with DateTime::Timezones, check out User::Timezone 15:42
raku.land/zef:guifa/User::Timezone
[Coke] do we have a writeup anywhere on how class Foo is Foo is better than augment? Can we fix augment to be better? 15:45
guifa [Coke] as I recall, class Foo is Foo doesn't touch the original; augment modifies it and thus breaks a lot of optimizations, but things may have changed in the years with various updates to dispatch etc 15:47
also technically class Foo is Foo doesn't potentially break stuff in other modules since they'll still rely on the core version 15:51
I had to do some blackmagic to effectively force upgrade all extant DateTimes 15:52
Voldenet btw `(run 'readlink', localtime-path, :out).out.slurp.chomp;` this is not needed 15:59
m: say "/etc/localtime".IO.resolve 16:00
camelia "/usr/share/zoneinfo/Europe/Vienna".IO
16:04 arkiuat joined
Voldenet it's a very neat trick now that I know it 16:08
it has some edge cases though 16:09
16:09 arkiuat left
Voldenet nevermind, it's just a nice trick 16:10
m: class Foo { has $.x = 4 }; { my class Foo is Foo { has $.x = 3 }; say Foo.new.x }; Foo.new.x.say # you can even change initial values for class in scope
camelia 3
4
16:11 abraxxa-home joined
Voldenet mL class Int is Int { method Foo { } }; 42.Foo 16:13
m: class Int is Int { method Foo { } }; 42.Foo
camelia No such method 'Foo' for invocant of type 'Int'
in block <unit> at <tmp> line 1
Voldenet of course
m: class Int is Int { method Foo { } }; Int.new(42).Foo # of course
camelia ( no output )
Voldenet and core classes very often will try to "downgrade" the object into the non-scoped one 16:21
16:30 arkiuat joined 16:35 arkiuat left
guifa yeah, that's because their methods will refer to their own ::?CLASS 16:35
Voldenet it's good for things that use by-reference semantics for everything, for everything else it's mental gymnastics 16:41
because suddenly there's two classes with exactly the same name - in dotnet you can load exactly the same assembly twice 16:42
and, obviously, IFoo from both instances of assembly is different - in fact this is the kind of problem you're going to get 16:43
m: class Int is Int { method Foo { } }; say so 42 ~~ Int 16:44
camelia False
Voldenet m: class Int is Int { method Foo { } }; say so 42 ~~ PARENT::Int 16:49
camelia True
disbot4 <jubilatious1_98524> @guifa "they should not handle it themselves" If you want to make a module to automatically convert timezones that's great--and more power to you. The rest of us just want to do Data Science in Raku and can pull from a database ourselves. Can we do that now? 16:52
<jubilatious1_98524> What does the change of DateTime to a 'value type' entail? What are the benefits? What are the losses? Where is the Github issue? 16:53
Voldenet well, DateTime::Timezones uses thin wrapper over Timezones::ZoneInfo that's actually "latest tzdb" 16:54
(tzdb format isn't really user friendly, it's not friendly at all :/) 16:58
16:58 skyesoss joined 17:03 arkiuat joined, skyesoss left
guifa I mean given it's probably the literal actual inspiration for that xkcd comic about the one dude in nebraska supporting everything.... lol 17:06
disbot4 <antononcube> FYI: xkcd.com/2347/ 17:07
guifa IIRC in DateTime::TImezones I added in two subsets if you really want to distinguish them
17:07 arkiuat left
guifa jubilatious: what I mean is that time is MUCH more complex than people realize 17:07
disbot4 <antononcube> I remember that XKCD comic, I did.t remember it's about someone from Nebraska... 17:08
guifa so it's better to leave it to battle tested modules / frameworks to handle that -- that's not a Raku thing, I'd say the same thing for anything in C / Java / etc
disbot4 <jubilatious1_98524> What's the Raku equivalent of the R Tidyverse lubridate package? lubridate.tidyverse.org
<antononcube> "Data::Reshapers"
<antononcube> See: rakuforprediction.wordpress.com/20...with-raku/ 17:09
guifa Depending on your end use, I'd recommend storing EITHER walltime OR an epoch offset, alongside a Olsen ID. You can then reconfigure that stuff pretty easily from there -- if you're doing scientific phenomena you'll probably be more concerned with the epoch, and any timezone stuff is just after-the-fact display (akin to localization) 17:10
disbot4 <antononcube> @jubilatious1_98524 Sorry, wrong answers from me about "lubridate". 17:11
<jubilatious1_98524> @guifa, I agree. I used to use the minimal base-R package to handle datetimes, whioch was Gabor Grothendeick's zoo package (mostly analyzing time differencesl manually in a CSV/Dataframe ): cran.r-project.org/web/packages/zoo/index.html
guifa the whole reason I ended up making the timezone package is because I was doing a port of Mozilla's Fluent
disbot4 <jubilatious1_98524> Zoo publication in the The Journal of Statistical Software (JSS): www.jstatsoft.org/article/view/v014i06 17:12
guifa (which I need to go back and update because for $DEITY's sake that's some of the ugliest Raku code I have publicly posted
disbot4 <jubilatious1_98524> I don't know anything about Mozilla's Fluent.
guifa it's a really nice open source localization framework 17:13
it was designed from the ground up to handle thing like cases and other weird numbers or syntax issues 17:14
disbot4 <antononcube> In some believe systems ugly children are also $DEITY's children.
<antononcube> I am not sure does that extent to programming code. 17:15
guifa The problem is that Fluent has a few built in functions
One of which formats date times
So that led me to do a datetime formatting module
disbot4 <jubilatious1_98524> All $DEITY's children are loved, even the ugly ones. 17:16
guifa But to do THAT, I needed CLDR info, so I made Intl::CLDR (which I still want to work on more to better optimize)
and then I got stuck with a final few formatters which were timezone ones, which CORE doesn't support, so I had to build that 17:17
It's been a huge journey ha
disbot4 <jubilatious1_98524> I hear ya.
guifa and then midway through development, RakuAST came out 17:18
so everything got rewritten for that 17:19
my last big thing is to make a DateTime::Calendars module 17:20
jforget has done some work there porting over p5 modules, but I want to find a way to fully do an augmentation of core like I did with timezones. 17:22
disbot4 <jubilatious1_98524> I tried handling ISO DateTimes in R using just the base classes and it didn't work. Well it worked, but not for my dataset, which collected data at irregular time intervals (base classes only handle regular intervals). I then found the zoo package which was a dream, and finally lubridate which is incredibly capable--if you want to put in the time to learn it.
<jubilatious1_98524> I've only tackled simple DateTime stuff with Raku, mostly format-conversions tk ISO 8601: unix.stackexchange.com/search?q=us...8+DateTime 17:24
guifa I've not done much with the conversions of times. Though I did make a toy little module that gives you a minutely, hourly, daily, weekly, dst-ly, yearly supply 17:27
17:31 arkiuat joined 17:35 arkiuat left 17:50 abraxxa-home left 17:51 abraxxa-home joined 17:52 abraxxa-home left 18:06 arkiuat joined 18:11 arkiuat left 18:32 arkiuat joined 18:36 arkiuat left
SmokeMachine Does anyone have any opinion on the new option on doing polymorphic relationships on Red? github.com/FCO/Red/blob/3eb8f31de4...-source-id 18:51
19:02 arkiuat joined
[Coke] anyone have a sample of cro http client submitting a form? 20:46
21:17 guifa left 21:36 stanrifkin joined 21:41 guifa joined 21:42 guifa left 21:50 guifa joined 22:20 arkiuat left 22:32 arkiuat joined 22:33 bdju left 22:35 bdju joined 22:36 arkiuat left 22:38 guifa left, guifa joined 22:58 guifa left 23:03 arkiuat joined 23:08 arkiuat left 23:10 guifa joined 23:30 arkiuat joined 23:35 arkiuat left 23:37 guifa left 23:48 arkiuat joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!