Raku
Methods 'julian-date' and 'modified-julian-date' have incomplete description
The methods are only defined for one timezone (UTC-0000) and cannot be converted to local time
There are currently no core methods to convert then to local time, but those routines are available in distribution 'DateTime::Julian'.
Such details are missing from the current descriptions, and this PR attempts to remedy that.
- Addresses doc issue #4577
- Addresses doc issue #4575
Currently, the example in the doc uses a DateTime that is already set to UT timezone Z, and so can't demonstrate this behavior. It might be helpful if there were an example using a DateTime object with a non-UT timezone, showing that the timezone information is silently disregarded.
The submitted commit 84df054c1dd4626a724b723248a07cc5025239c4 is a big improvement on what's currently there, but what would be even more helpful is a recommendation to doc-readers advising to code the silent behavior explicitly, by always prefixing .julian-date with .utc (e. g. $dt.utc.julian-date) whenever applying it to DateTime objects for which the timezone status is unknown.
I thought these were two separate issues because I didn't think my issue had anything to do with converting to local time, and didn't see any need to mention non-core modules.
My point is one should not normally need a .julian-date for a given timezone. Your method doesn't actually mean much.
Maybe say that in the docs, but be aware [Coke] is very picky about going much afield for examples and such. So an example showing the no-julian-date change would be better in a roast test IMHO.
Perhaps mention the .utc method, so that:
$ raku -e 'for -11..11 {DateTime.new("2025-05-19T17:00:00"~"%+03d".sprintf($_)).utc.julian-date.say}' 2460815.666667 2460815.625 2460815.583333 2460815.541667 2460815.5 2460815.458333 2460815.416667 2460815.375 2460815.333333 2460815.291667 2460815.25 2460815.208333 2460815.166667 2460815.125 2460815.083333 2460815.041667 2460815 2460814.958333 2460814.916667 2460814.875 2460814.833333 2460814.791667 2460814.75
? Or am I missing something?
On 22 May 2025, at 00:27, Tom Browder @.***> wrote:
tbrowder left a comment (Raku/doc#4578) My point is one should not normally need a .julian-date for a given timezone. Your method doesn't actually mean much. Maybe say that in the docs, but be aware [Coke] is very picky about going much afield for examples and such. So an example showing the no-julian-date change would be better in a roast test IMHO. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>
I'll do something like that, but I'll shorten it. I'll work on it tomorrow.
@arkiuat, @tbrowder - what’s the status on this? Is there another PR that I should prefer, or...
Will, I'm baffled and don't know what to so with this now. I think it may have become moot after other changes.
@arkiuat, @tbrowder - what’s the status on this? Is there another PR that I should prefer, or...
That's a good question. I was just beginning to learn how to use github when I was working on this: the PR now references two closed issues, #4575 and #4577, but doesn't reference the open issue #4581.
My original concern was to have something in the docs alerting users to the fact that using .julian-date without first applying the .utc method would discard any timezone information in the DateTime object.
I'm pretty sure I'm not the only one who ever got confused that it shouldn't be the other way around, but I keep getting bogged down trying to come up with a code example that demonstrates this clearly, golfed down to the bare minimum. The last one I came up with looks vaguely ridiculous to me:
sub tz ($h) { DateTime.new(-4712, 1, 1, 1, 1, 1 :timezone(60*60*$h)) }
.say for (^2).map: { tz($_).julian-date } # OUTPUT: «37.54237337.542373»
.say for (^2).map: { tz($_).utc.julian-date } # OUTPUT: «37.54237337.500706»