|
🦋 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
|
|||