There is currently a PR on the repo with very lively discussion about what the following operation should do: using Dates a = now() b = a + Nanosecond(1) (the situation is analogous with Microsecond) Currently, the result is always exactly equal to a, because the DateTime arithmetic implemented…

[image] mihalybaci: It would appear that the decision has already been made to end leapseconds. This does not change the dilemma we have (even if the concept of a leap second had never been invented, for any standard): From 2035, leap seconds will be abandoned for 100 years or so and will p…

[image] Palli: First the easiest part to disagree with “you also want nanosecond precision for dates in BCE 753”. The first use case I can think of where someone might want better precision is the very specific subfield of archaeoastronomy. Examples: trying to find the sky location of a possi…

[image] mihalybaci: I’m not an archaeoastronomer, but it seems to be a good assumption that no one is going to run a simulation backwards 7000 years with attosecond precision. Well, I can well imagine such a simulation as a PhD topic. Actually a great topic: Put your predictions a couple deca…

Here is one case I remember specifically from this “forensic astronomer” , who estimated down to the minute when Monet was painting a sunrise in 1835. (I tried to find a link that would work for everyone, apologies if it doesn’t). And things are surely chaotic to a small degree, but it is still possi…

Surely astronomy belongs to the so-called exact sciences, which are called so not because they “admit of absolute precision in their results”, as Wikipedia maintains , but, by the definition I like most, because they make it possible to estimate the reliability of their results. It is probably possi…

Maybe I missed that part of the discussion, because it’s such an obvious suggestion but… why not make DateTime parametric? Then you could keep the current behaviour as is by default, while supporting extra precision with eg. DateTime{Int128}. On our side, doubling the memory requirement of DateTime …

Sir Isaac Newton used some of these techniques to date ancient civilizations, once navigation by stars was invented. Not sure if this is a use case for some of these packages. I did not personally try to reproduce the math. If you find problems with the math I can bring it to the editor’s attenti…

[image] cstjean: why not make DateTime parametric? I wonder if that would be considered a breaking change. Maybe not technically breaking, but it could slow down code that assumes DateTime is a concrete type. For example, this struct would go from having concretely typed fields to having abst…

I’ll toss in my 2 cents here. One of the threads throughout this conversation has been (both explicitly and implicitly at various points) that maybe more precise DateTimes, wider epochs, etc. should be done in a package for users that need that functionality. I don’t disagree and AstroTime.jl and Na…

[image] cstjean: why not make DateTime parametric? Or make a new struct: PreciseDateTime{T} Which is parametric but leave the existing DateTime alone… But make adding a Nanosecond(1) to a DateTime promote to PreciseDateTime{Int128} by default?

`DateTime` arithmetic on `Microsecond` (or smaller) scale

Internals & Design

Topic		Replies	Views
TimesDates.jl dev for v2 Specific Domains dates , time , internals	44	2493	September 14, 2023
Higher resolution DateTime/TimeStamp Internals & Design dates	44	10574	February 13, 2019
Why do time quantities have to be integers? Internals & Design question	56	5327	February 5, 2018
Differences smaller than Dates.Milliseconds are ignored Internals & Design question , bug , dates	7	785	July 6, 2019
Universal Time vs UTC Time in Dates General Usage dates	11	1746	August 26, 2023

`DateTime` arithmetic on `Microsecond` (or smaller) scale

Related topics