01:30 nine left, nine joined 01:56 hulk joined 01:58 kylese left 02:08 m6locks left, m6locks joined 02:15 hulk left, kylese joined 02:38 tjr left 03:28 simona24 left 03:48 Aedil joined 05:03 [Coke] left 05:06 [Coke] joined 05:30 Sgeo left
japhb Awww timo, thank you! 06:25
Hi patrickb!
07:46 sena_kun joined 08:15 dakkar joined 08:42 euandreh left 08:44 euandreh joined 08:52 kst left, kst joined 09:46 tjr joined 14:35 jjido joined 14:42 jjido left
tonyo wjem we 15:00
when we're writing pod6, is `=begin pod` necessary to distinguish between pod and 6 or is just getting into the pod itself in a rakumod file fine enough? 15:01
lizmat lines that start with =foo will always be rakudoc, is that an answer ? 15:06
ugexe Why does docs.raku.org/language/pod read "Every Pod6 document has to begin with =begin pod and end with =end pod. " then? 15:40
i presumed this is because it distinguished POD from rakudoc 15:41
[Coke] rakudoc (the new stuff) isn't in raku/doc yet.
I think that was waiting for the rakudoc-gamma work to be complete. 15:42
ugexe let me rephrase then: is that be design or by coincidence
[Coke] is what by design? 15:44
the docs?
ugexe not requiring a begin/end ala =begin pod 15:45
if it is be design then i could remove the e.g. =begin pod in my code 15:50
lizmat fwiw, there is talk about the .rakudoc extension forcing an implicit =begin rakudoc / =end rakudoc around the contents of the file, to ensure no code can run 15:51
ugexe makes sense. all my rakudoc is inline though 15:52
16:06 dutchie left
lucs I really don't like the idea in general of forcing a behaviour based on the name or extension of a file. 16:06
16:06 dutchie joined 16:34 dakkar left
tonyo [Coke]: is the rakudoc grammar somewhere i can look at? 16:45
assuming that's what rakudoc-gamma means
lizmat src/Raku/Grammar.nqp 16:50
tonyo dank 16:56
jdv dank ipa by sierra nevada is not bad 17:01
mine wife appreciates it
17:13 jjido joined 17:26 jjido left
Xliff m: say "Boo!" if DateTime.new(0) 17:33
camelia Boo!
Xliff Hmmm... that looks like a thinko.
I would suspect DateTime.new(0) would be falsey.
Would this break things? 17:34
tonyo why would that be falsey? 17:35
it's jan 1, 1970 17:36
m: say DateTime.new(0).yyyy-mm-dd; 17:37
camelia 1970-01-01
17:50 Aedil left
patrickb github.com/Raku/RakuDoc-GAMMA/issu...2351867123 18:16
tony-o: That's the issue about having rakudoc be pure RakuDoc. 18:17
19:23 sena_kun left 19:25 jjido joined
tonyo ty 19:39
are the rakudocs meant to be side by side the rakumods or in a `doc/` folder? 20:40
[Coke] anyone have a good primer on dealing with saving datetimes with an arbitrary "author" timezone and then rendering correctly in an arbitrary "viewer" timezone that doesn't run afoul of DST issues for future events across the change point? I think the key has to be using the "generic" timezones on both ends and hoping your datetime library is smart. 20:58
tonyo: I don't think anything cares about that right now. 20:59
when we do start caring about it, raku/rakudoc will be much more useful.
(where a generic timezone is "ET" instead of being explicit about EDT/EST)
tonyo every time i've needed to worry about TZ at work, i store it in UTC and convert to the user's TZ at render time 21:00
[Coke] right - but if I am in EST now, and store an event that would occur in EDT in the future, my offset is probably off by on the UTC, yes? 21:05
(time zones suck) 21:06
tonyo it depends on the future, if you are EST now and convert to UTC it'll be an offset of zero (1900 -> 2400). when you convert back to EDT it'll be 2000, which is what you'd expect if you went from EST to EDT 21:07
or are you meaning you'd want to handle it more generically, treating the offset in more of a America/New_York way where the offset is: `-4 - light saving status ? 1 : 0;` 21:09
so it always comes back as 1900
[Coke] if my offset is 5 now, and I save it for a date that is in EDT, the -5 doesn't know that it should be -4 then.
tonyo store it as offset zero 21:10
and convert back to _whatever the offset of the user is when needed_
[Coke] ... I still have to *do the conversion* when I save it.
tonyo it sounds like you want it to come back as 1900 regardless of the day light savings status ? 21:11
[Coke] and that conversion is off by one at that point. let me write up a specific example with numbrs.
tonyo (as long as you're in ET)
[Coke] I want it to be *correct*. :)
let me write a specific example. Maybe I'm overthinking it.
tonyo it is correct if it comes back as 1900 EST and 2000 EDT
but seems wrong, i think is part of the problem 21:12
21:14 jjido left
[Coke] gist.github.com/coke/773740d69fbbe...aba6168ad5 21:17
Why should it change?
I am trying to record a specific time in the future.
oh, I see.
*(what you're saying)
but then you're using two different timezones for one event, that only has one time zone 21:18
it doesn't make sense to a human to say "show me this event that occurs during DST as if it were in Standard time"
tonyo if you want it to restore to the *same* time when doing the conversion you need to convert to UTC and add the DST offset of the timezone 21:19
[Coke] I don't want it to be the same for EST and EDT
tonyo so if you're in EDT (offset of 1 hour) and you want to store a date in EST you'd convert 1900 -> UTC (0000, DST offset: 0100). then in converting to EDT to EST you'd convert to local timezone + the difference in DST offset (0000 UTC -> EDT -> 2000 - (0000 - 0100) -> 1900) 21:20
since some TZs have 15 minute or whatever offsets you need to keep track of what it was when the date was created but still store the date in UTC 21:21
[Coke] Right, so you either need to manually track when DS/Non boundaries occur to do that, or: use the "generic" timezone and hope your library is smart.
tonyo you only need to convert to UTC and keep track of the DST offset of the user's current TZ 21:22
if you write up a gist of what the input -> output is expected i can help you go through it
[Coke] worse: the legacy system I'm looking at just has "Eastern Standard Time" - whoever setup the original list of timezones this thing is using didn't use the generic ones, or DST. 21:23
tonyo yikes
if it's any consolation the company i work for now uses a broadcast calendar that is off by a week every quarter for a very similar reason. it trips up almost everyone 21:24
err DST trips up almost everyone
[Coke] our company has a lot of staff in India, so I also get the fun "half the meetings I'm on shift by 30m" whenever we cross a boundary here in the US. 21:25
depends on who setup the call, US or India.
hah. trying to setup my data, I use dateful.com/convert/utc - when I try to force it to do something stupid (which I think is the default code path that my project is heading towards), it says "Did you mean EST (Eastern Standard Time)? 21:31
The Eastern United States currently observes EST, not EDT.
"
(for the date in the future that I was trying to use EDT for. :)
tbrowder once 21:32
: 21:36
check out my modue DateTime::US for use with Raku apps 21:38
tonyo [Coke]: i think the difficulty in handling that (in either way i've put up above) is that some people think one is the correct way and others think the other is the correct way. neither are correct from a math or usability perspective 21:51
22:00 Sgeo joined 22:13 itaipu left 22:27 itaipu joined
tonyo [Coke]: this thread has some good info in it about how to handle what you're wanting www.reddit.com/r/csharp/comments/t...t/i2jyjju/ 22:28
[Coke] tonyo: thanks 22:38
23:40 euandreh left 23:42 euandreh 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!