Function and Workspace Timestamps

Comments:

Author Thread:

Support

Function and Workspace Timestamps
Posted: Monday, May 02, 2005 11:25 AM (EST)

The current behavior is by design per page 1-6 in the 5.0 Update Manual.

APL2000 Support


brent.hildebrand

Function and Workspace Timestamps
Posted: Monday, May 02, 2005 12:19 PM (EST)

I read the above section in v5 update docs as changes to the Session manager's display of timestamps. I'm speaking about 2 []AT and []WSTS. Particularly 2 []AT, which is not a session issue. If I save a function saved in a EDT timezone, then load that workspace in a PDT timezone, the time reported will be that of EDT timezone, but with no information that it was saved in EDT. These timestamps are saved in Local time. This issue is not huge, and I've never ran into it before until colaborating on a project where we were exchanging workspaces across the Atlantic multiple times a day.


Mark.Osborne

Function and Workspace Timestamps
Posted: Monday, May 02, 2005 12:38 PM (EST)

Yes, using local time for workspace and file timestamps was a mistake. It was a historical compatibility problem. I believe the Unix system from which APL+Win derives stores the timestamps in UTC and reports them in local time. But when APL*PLUS Unix code was ported to DOS to become the APL*PLUS II/386 system, we maintained compatibility with APL*PLUS/PC in this area. So we have local timestamps and a different epoch. And this was carried into Quad-AT as well.

Note that even if you had the local time zone information, it is still not possible to reverse all times from local to UTC because of things like daylight savings time.

It's problematic to reverse these decisions now, since it would create an aberation in the continuity of timestamps. We have tried to not continue the mistake. The Colossal file system stores UTC timestamps.

The problems with timestamps in the system run deeper than just UTC vs local time. There are different epochs used in the two systems and the underlying OS's use different epochs again. And even within an OS, there are different functions dealing with different time bases. We've woven quite a few internal problems from this yarn. I attempted to straighten it out a few years back to enable use of international timestamps. There is a long set of comments on this in the code, which describes the mistakes made and how we have attempted to resolve them for future work.

We should learn from this and make sure that the new systems and new features all use UTC.

/Mark



William.Rutiser

Function and Workspace Timestamps
Posted: Monday, May 02, 2005 1:03 PM (EST)

When I joined STSC in 1977, there was already an argument as to whether the main-frame time sharing systems should keep and display time in UTC or EST. Systems programmers said UTC but marketing types said EST because it would be easier for customers to understand. The PC interpreter generally followed the time-sharing system. Besides, PCDOS didn't know about time zones. And who expected the internet???


davin.church

Function and Workspace Timestamps
Posted: Monday, May 02, 2005 1:50 PM (EST)

FYI - I have routines that convert timestamps back and forth between local and UTC time, if you need to implement such things in your applications. It takes into account DST and works with dates that are not in the same DST setting as you are (which Windows has traditionally had trouble with). The only difficulty is the ONE hour per year in which the local to UTC conversion is indeterminate (in which case one of the two possible answers is consistently returned).


brent.hildebrand

Function and Workspace Timestamps
Posted: Monday, May 02, 2005 4:09 PM (EST)

I have a little APL function using the GetSystemTime API to produce a result similar to []TS.

    ’ ret„TSutc
[1]   ret„(Œioœ163 323 Œdr Œwcall 'GetSystemTime' (16/Œav[Œio]))[Œio+0 1 3 4 5 6 7]
    ’

[]TS and TSutc compared
      Œts ª TSutc
2005 5 2 12 59 51 191
2005 5 2 19 59 51 191

I assume - maybe naively - that this works even during that 1 hour of the year. It is not a conversion routine, just a UTC time routine.

Off Topic:

Is the download server on APLDN offline

BH



davin.church

Function and Workspace Timestamps
Posted: Monday, May 02, 2005 4:50 PM (EST)

That only works to give you current time, whereas my routines convert arbitrary timestamps at any time of the year.


brent.hildebrand

Function and Workspace Timestamps
Posted: Monday, May 02, 2005 4:58 PM (EST)

As I said, it is not a conversion routine. Just a UTC replacement for []TS.


Support

Function and Workspace Timestamps
Posted: Monday, May 02, 2005 5:23 PM (EST)

Yes, the download server is currently offline. We are investigating the problem and hope to have it back online shortly.

APL2000 Support



Support

Function and Workspace Timestamps
Posted: Tuesday, May 03, 2005 12:00 PM (EST)

The APLDN download server is now operational.

APL2000 Support