🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
04:14 librasteve_ left 04:24 rakkable left, rakkable joined 05:17 SmokeMachine left, leont left 05:18 kjp left 05:19 kjp joined 05:21 leont joined, SmokeMachine joined 05:31 rir_ joined 05:35 rir left 07:12 kjp left 07:13 kjp joined 07:14 kjp left 07:15 kjp joined 12:12 finanalyst left 12:58 rir_ left 14:00 librasteve_ joined 14:48 nativecallable6 left, benchable6 left, bloatable6 left, quotable6 left, releasable6 left, shareable6 left, greppable6 left, tellable6 left 14:51 bloatable6 joined 14:52 linkable6 joined, notable6 joined, nativecallable6 joined, tellable6 joined, unicodable6 joined, releasable6 joined, evalable6 joined, benchable6 joined 14:53 committable6 joined, shareable6 joined, bisectable6 joined, quotable6 joined, sourceable6 joined 14:54 greppable6 joined, coverable6 joined
lizmat m: say DateTime.now.WHICH # why isn't DateTime a value type ? 18:35
camelia DateTime|6333426610864
lizmat m: dd DateTime.now.WHICH # why isn't DateTime a value type ? 18:36
camelia ObjAt.new("DateTime|6222529192624")
timo was DateTime a type that can hold a timezone? 18:37
lizmat yes
but the .in-timezone method returns a new DateTime object, so still immutable afaics 18:38
timo ah, so the ValueObjAt would have the timezone as well 18:39
lizmat yup
well, could/should :-)
m: say DateTime.now # stringification should be fine for .WHICH 18:40
camelia 2025-07-20T20:40:34.408097+02:00
timo except that's slower than for example hexadecimal-ing the number
+ the time offset 18:41
otherwise yeah
lizmat which number ?
timo 6333426610864 18:42
lizmat that's the memory address of that instance
timo oh!
i meant the unix timestamp behind the object 18:43
SmokeMachine No one asked me… but I agree that should be a value type…
lizmat there is none, one can be created
timo oh, the datetime object has date bits inside? 18:44
i should think more before speaking, clearly
lizmat anyways.. it looks like DateTime *can* be mutated if an instance lives past a daylight saving change
yuck 18:45
SmokeMachine :( 18:47
Could it be avoided?
lizmat perhaps, at a language level change, and making clear that it will *not* properly report instances during a daylight saving change event 18:50
but that feels like we would be introducing action at a distance 18:51
timo if the datetime has a timezone set in it, it would have to have either the one or the other to refer to the correct moment
lizmat well, that's the thing: we don't force setting a timezone on a DateTime object 18:52
hmm... maybe I'm reading this wrong 18:53
timo if you've got a DateTime without a timezone, it refers to many different moments, subject to interpretation 18:54
before vs after a "local timezone has changed its offset" event is simply a difference in interpretation that can catch you off-guard if your code is naive. ideally we would make it as easy as possible to not get caught off guard, but that results in having to write verbose code that seems unnecessarily complicated for all times except when something weird happens 18:56
lizmat ok, so maybe it should be a ValueObjAt after all
releasable6 Next release in ≈38 days and ≈23 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 19:00
23:41 librasteve_ left 23:49 guifa joined