medley
medley copied to clipboard
Interlisp
Do we have the right daylight savings days?
\UNPACKDATE seems to return an hour that is one less than our current DST clock time. But its return value-component to say that it is DST is NIL, at least today. If you give it a date from a week or so ago, it gets it right, or a week have Novermber 7.
I think it doesn't have the right settings for the begin/end of DST. Constants in IOCHAR?
Almost certainly the wrong DST days. We used to update them in the PARC-INIT but I don't think they got updated in the system sources.
DST adjustments are location dependent as are time zones. And date-times in the past are often wacky with regard to a recorded local time being DST or not.
Can you rely on the host operating system for this, using UTC in interchange and as the internal reference date-time?
E.g., this year the EU (and UK) go off DST at their 1 am October 31, when it starts locally in some regions of Australia :). The US goes off DST in the early hours of November 7.
(Observation made in ignorance of how \UNPACKDATE is expected to work.)
look at https://github.com/Interlisp/maiko/blob/master/src/timer.c and
grep -lri "time.*zone" maiko
on the inside story. I thought I saw a subr or something to get the UNIX timezone.
there are files that have embedded dates in "FILECREATED" expressions and are off systematically. But it could be someone was running with their clock set wrong.
i don't see the need to solve this. Yes, Interlisp dates don't have timezones. Is there a problem? Interlisp doesn't rely on file dates so much.
I don't remember understanding why secure systems need accurate clocks
@masinter
I don't remember understanding why secure systems need accurate clocks
Addendum: There are also timestamp services that I presume require some level of time synchronization. These are used as adjuncts to digital signatures, attesting to the verification of the signature at the time indicated and useful when the signature cert expires or is revoked later. It can be taken as an affirmation that the the signature was "good" at the time. This is recommended for code signing. Might be relevant for docker images related to this project :).
I think (DATE) is off by an hour right now. Shouldn’t we at least try to be accurate?
On Oct 24, 2021, at 7:36 PM, Larry Masinter @.***> wrote:
look at https://github.com/Interlisp/maiko/blob/master/src/timer.c https://github.com/Interlisp/maiko/blob/master/src/timer.c and
grep -lri "time.*zone" maiko on the inside story. I thought I saw a subr or something to get the UNIX timezone.
there are files that have embedded dates in "FILECREATED" expressions and are off systematically. But it could be someone was running with their clock set wrong.
i don't see the need to solve this. Yes, Interlisp dates don't have timezones. Is there a problem? Interlisp doesn't rely on file dates so much.
I don't remember understanding why secure systems need accurate clocks
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/544#issuecomment-950474846, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJJKQG6T6MFU3CDATXTUIS7C3ANCNFSM5GT5RTLQ.
Set \EndDST to 1 more than it is currently and it will get at least today's time correct.
On Oct 24, 2021, at 9:22 PM, rmkaplan @.***> wrote:
I think (DATE) is off by an hour right now. Shouldn’t we at least try to be accurate?
On Oct 24, 2021, at 7:36 PM, Larry Masinter @.***> wrote:
look at https://github.com/Interlisp/maiko/blob/master/src/timer.c https://github.com/Interlisp/maiko/blob/master/src/timer.c and
grep -lri "time.*zone" maiko on the inside story. I thought I saw a subr or something to get the UNIX timezone.
there are files that have embedded dates in "FILECREATED" expressions and are off systematically. But it could be someone was running with their clock set wrong.
i don't see the need to solve this. Yes, Interlisp dates don't have timezones. Is there a problem? Interlisp doesn't rely on file dates so much.
I don't remember understanding why secure systems need accurate clocks
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/544#issuecomment-950474846, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJJKQG6T6MFU3CDATXTUIS7C3ANCNFSM5GT5RTLQ.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/544#issuecomment-950514410, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6DAWLR6PW2PICDCXWNNE3UITLORANCNFSM5GT5RTLQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Documentation (as of 1985) says
\BeginDST is the day of the year on or before which Daylight Savings Time takes effect (i.e., the Sunday on or immediately preceding this day); \EndDST is the day on or before which Daylight Savings Time ends. Days are numbered with 1 being January 1, and counting the days as for a leap year. In the USA where Daylight Savings Time is observed, \BeginDST = 121 and \EndDST =305. In a region where Daylight Savings Time is not observed at all, set \BeginDST to 367.
The current US situation, for those states that observe DST, is that it starts on or before March 14, day 74 in a leap year and it ends on or before November 7, day 312 in a leap year. They're currently set to 98 and 304.
The variable \EndDST is indeed set to 304 (today is day 297). So must be controlled by something else.
On Oct 24, 2021, at 10:13 PM, Nick Briggs @.***> wrote:
Documentation (as of 1985) says
\BeginDST is the day of the year on or before which Daylight Savings Time takes effect (i.e., the Sunday on or immediately preceding this day); \EndDST is the day on or before which Daylight Savings Time ends. Days are numbered with 1 being January 1, and counting the days as for a leap year. In the USA where Daylight Savings Time is observed, \BeginDST = 121 and \EndDST =305. In a region where Daylight Savings Time is not observed at all, set \BeginDST to 367.
The current US situation, for those states that observe DST, is that it starts on or before March 14, day 74 in a leap year and it ends on or before November 7, day 312 in a leap year. They're currently set to 98 and 304.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/544#issuecomment-950534140, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJKDDXSQDV2XV4TMYRLUITROLANCNFSM5GT5RTLQ.
Documentation (as of 1985) says ... The current US situation, for those states that observe DST, is that it starts on or before March 14, day 74 in a leap year and it ends on or before November 7, day 312 in a leap year. They're currently set to 98 and 304.
I suppose Interlisp can be forgiven for not reflecting the US changes that went into effect for the first time in 2007. https://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States
Is this being discussed relative to where an instance of Interlisp is running or what?
@orcmid -- Ron is here in the US, and the DST defaults in Interlisp have always been set for the US, but they're set up in global variables not constants so they're easy to modify. The algorithm that takes them as input to determine if it's DST or not (and tries in a sort of half-hearted way to come up with a time zone name) is also US-centric, but again, if it's wrong then one can replace the code in one's site (or personal) init file.
Of course Interlisp could set the DST and time zone from the underlying host, but what does that mean in a world where I'm running an instance in the cloud and the host is not in "my" time zone or even my country?
@nbriggs
Of course Interlisp could set the DST and time zone from the underlying host, but what does that mean in a world where I'm running an instance in the cloud and the host is not in "my" time zone or even my country?
That's not a new problem. Remote hosting also adds a time-of-day consideration. I suspect ground truth is where the instance is running, maybe normalized to UTC (so it is easy to adjust for different remote-access offsets when there is sufficient information). Whether this problem (needs to)/can be solved beyond that for Interlisp is maybe out of scope.
@orcmid Agreed. There are no deep philosophical issues that we're addressing here. Ron has fixed the default DST days for USA 2021 and forward. Anyone who wants a different presentation can trivially set different values in their personal customization file.
But a side note: the variables for begin and end are slashed (\BeginDST, \EndDST), which suggests that users should not set them. Maybe that should be changed and these should be more public.
On Oct 25, 2021, at 1:38 PM, Nick Briggs @.***> wrote:
@orcmid https://github.com/orcmid Agreed. There are no deep philosophical issues that we're addressing here. Ron has fixed the default DST days for USA 2021 and forward. Anyone who wants a different presentation can trivially set different values in their personal customization file.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/544#issuecomment-951309669, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJPAA3CXXNE3L6XOET3UIW55TANCNFSM5GT5RTLQ.
I read \ as... don't set this unless you know what you're doing. In this case that's because they are NOT the first and last day number of DST for this year, they're the first and last day, in LEAP YEAR numbering of the last Sunday on before which the time changes. Given that they're documented in the IRM since forever, I wouldn't change them.
Yeah, it's the time and basic timezone but not the daylight saving time period which doesn't come through that interface.
Right, it's \NS.SETTIME (whose definition is clobbered by MAIKO)
that gets the time zone from the XNS time service.
Is there no equivalent SUBRCALL?
TCP/IP NTP time protocol does not deal with time zones or DST at all, it just establishes time in seconds (and fraction) from 1970. In the Linux runtime code, there is a fairly large (and probably messy) table that isn't just the days it changes now, but for all years so that the time format transformation calls do the right thing for past dates too. This means there are updates to the Linux code tree that get pushed out every time the DST laws change somewhere. Conversions in time format are handled in the C libraries. I think it would be possible to write code that could deduce the magic numbers. I don't think the Interlisp user base will be large enough anytime soon to be worth doing the "right thing".
Yeah, absolutely, which is why the values are trivially settable by anyone who wants to put them in a site or personal init file, without recompilation or anything magic… ;-)
Belongs in the FAQ and intro to running Medley... especially a problem for online users since the user could be coming from anywhere. There are filedate problems for FILECREATED dates because DATE and IDATE don't do anything with TimeZone info .
It's probably safe to use a universal time (whether seconds from an origin), as long as the origin timezone is understood. I assume that is UTC in modern systems. Some operating systems don't handle that with regard to showing local time properly and/or stamping local files properly. With regard to persistent dates of a "now" somewhere, it should be "now" where the date is affixed. If that is always UTC, then it is easy for an observer to convert to their relevant local time. That seems to work on email that I receive from international origins.
I think it is amazing that Linux handles retrospective daylight rules. It is annoying for me that my Outlook Calendar makes a mess of it when I look back at older entries.
With regard to Interlisp adoption, look at it this way. The user base can't get internationally (or even nationally) larger if this is not handled. And whatever course is taken, it must be sensible to some degree of sensibility.
As I type this, there are 43,457 of over a million users active in the Second Life virtual world. The local "SL Time" is 9:39 AM. That happens to be USA California local time and everyone copes with that. All in-game times are recorded in SL Time, including on timestamps of messages. I don't mind. I live in the same time zone :). The fixed, predictable nature of SL Time is something all can deal with, including the contrary (to the Southern Hemisphere) or offset differences in daylight times, where those occur.
And I adjust my head around the time of distant connections the same as I would in arranging or participating in conference calls and web casts, the last two being in Haifa and in Melbourne, respectively.