You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As far as I can tell, we only store two kinds of values in a javascript Date object:
The time of a fixed astronomical event (in UTC). This might be a moment of sunset, the moment of a new moon, the spring equinox, or so on.
A gregorian day at a fixed time (e.g. midnight).
In some cases we store both kinds of values in one variable at different times (e.g. when computing the new moons)
I think we should use different names for the first two kinds of variables (e.g. utcFoobar or dateFoobar), and introduce new variables to account for the third kind. This would certainly be an improvement over the original variable names, which admittedly aren't that informative. We can do something similar for function names.
As an example, this was partially done in find_naw_ruz in the old code, where some variables ended with _day and others ended with _utc. But that wasn't systematic. What would actually be really ideal is to rewrite the code with a different type for a gregorian day (e.g. month/day/year) and only use Date objects for UTC. I don't know if doing that refactor is worth it though.
As far as I can tell there are no other "types" of variables where we store time, but if for some reason we ever stored something with localtime we might name that variable differently.
The text was updated successfully, but these errors were encountered:
As far as I can tell, we only store two kinds of values in a javascript Date object:
I think we should use different names for the first two kinds of variables (e.g. utcFoobar or dateFoobar), and introduce new variables to account for the third kind. This would certainly be an improvement over the original variable names, which admittedly aren't that informative. We can do something similar for function names.
As an example, this was partially done in find_naw_ruz in the old code, where some variables ended with _day and others ended with _utc. But that wasn't systematic. What would actually be really ideal is to rewrite the code with a different type for a gregorian day (e.g. month/day/year) and only use Date objects for UTC. I don't know if doing that refactor is worth it though.
As far as I can tell there are no other "types" of variables where we store time, but if for some reason we ever stored something with localtime we might name that variable differently.
The text was updated successfully, but these errors were encountered: