RE: Type for Current Time Function
From: Ashley Yakeley [mailto:ashley@semantic.org]
The most basic or at least the most obvious function in a time library is one that gets the current time. What is its return type?
getCurrentTime :: IO ???
It looks as though POSIX should be avoided, so I vote for (days, ticks). Is there some reason it couldn't (shouldn't) be an opaque type? i.e. with functions to convert to-and-from: - (days, ticks) - seconds since epoch - Calendar Time (in various calendars and timezones, etc) - other arbitrary representations ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************
In article
<7DFF3BC6CA957441AEADA7F340BFAA340A029338@GBLONEX11.lon.invesco.com>,
"Bayley, Alistair"
It looks as though POSIX should be avoided, so I vote for (days, ticks). Is there some reason it couldn't (shouldn't) be an opaque type?
That's an option, but we'd still have to decide what to put inside it. -- Ashley Yakeley, Seattle WA
On 2005 February 04 Friday 07:03, Bayley, Alistair wrote:
From: Ashley Yakeley [mailto:ashley@semantic.org] getCurrentTime :: IO ???
It looks as though POSIX should be avoided, so I vote for (days, ticks).
That would be fine, for starters. In addition, since the choice is based on the inadequacies of POSIX time, there should be an alternative which returns the raw POSIX time. Right now on my computer, the relationship between POSIX time and UTC is simple. A few years from now, when NTP is revised to provide access to TIA offsets, I hope that getCurrentTime will yield steady results during leap seconds. POSIX time will continue to be supported and will still be used for file system timestamps. So there's a need for a distinct data type for POSIX time, which would be used by file utilities, and for a getCurrentFileSysTime :: IO FileSysTime
On 04 February 2005 12:03, Bayley, Alistair wrote:
From: Ashley Yakeley [mailto:ashley@semantic.org]
The most basic or at least the most obvious function in a time library is one that gets the current time. What is its return type?
getCurrentTime :: IO ???
It looks as though POSIX should be avoided, so I vote for (days, ticks). Is there some reason it couldn't (shouldn't) be an opaque type? i.e. with functions to convert to-and-from: - (days, ticks) - seconds since epoch - Calendar Time (in various calendars and timezones, etc) - other arbitrary representations
I think I don't really understand the (days,ticks) representation. Could somebody explain the meaning of arithmetic on this type? Is the ticks field supposed to be limited to a day's worth? Or a day + a leap second? Can I add ticks to a time? If so, don't you need leap second info to do the normalisation? Or, if normalisation doesn't happen, you need leap second info to convert to UTC, right? The only conclusion seems to be that either you can't add ticks to a time, or you need leap second info which is what we're trying to avoid. Perhaps I missed something... :-S Cheers, Simon
On 2005 February 04 Friday 10:10, Simon Marlow wrote:
I think I don't really understand the (days,ticks) representation. Could somebody explain the meaning of arithmetic on this type? Its virtues are that it corresponds to UTC (including leap seconds) and doesn't have any more fields than necessary.
With UTC, leap seconds are involved if you're doing arithmetic down to the level of seconds or more finely. IMO the default should be to use the most up-to-date leap second information available. For some purposes, calculations that ignore leap seconds will be desired. As Ashley said,
There seems to be consensus that it should be some kind of encoding of UTC rather than TAI. Given UTC, questions of how to ticks or seconds will arise regardless of representation.
In article
I think I don't really understand the (days,ticks) representation. Could somebody explain the meaning of arithmetic on this type?
Is the ticks field supposed to be limited to a day's worth? Or a day + a leap second?
"Days" is an integer day number. "Ticks" is the amount of time since UTC midnight. It's limited to 86401 seconds. If this were picoseconds, its maximum value would be 86400999999999999 for the last picosecond in a day with a leap-second.
Can I add ticks to a time? If so, don't you need leap second info to do the normalisation? Or, if normalisation doesn't happen, you need leap second info to convert to UTC, right? The only conclusion seems to be that either you can't add ticks to a time, or you need leap second info which is what we're trying to avoid.
Perhaps I missed something... :-S
If you have two UTC times, there isn't always a way to know whether or not there was an intervening leap second, so there's no way to find out the absolute length of time between them. We don't have a source of TAI, and we don't have a leap-second table, so this is unavoidable: we simply don't have a uniform scale of time. Arithmetic on UTC times is going to ignore leap-seconds. It will be convenient for "calendrical" time however. For instance, there was a leap second at the end of 1998: 9:00:00pm, Dec 31st 1998 UTC + 5 hours UTC = 2:00:00am, Jan 1st 1999 UTC 2:00:00am, Jan 1st 1999 UTC + 5 hours UTC = 7:00:00am, Jan 1st 1999 UTC Because of the intervening leap-second, "5 hours UTC" is actually one second longer than "5 hours TAI" in the first sum, but the same in the second sum. In other words, it doesn't represent a fixed amount of time (just as "5 hours UT1" doesn't). There's also the matter of the leap second edge case as well. However, all the times are nice and clean when expressed in UTC. This is better for some applications (such as datebooks) and worse for others. How is this better than POSIX time? Mostly it isn't. The difference is that a (date,ticks) pair can represent UTC time unambiguously, whereas POSIX time cannot. -- Ashley Yakeley, Seattle WA
participants (4)
-
Ashley Yakeley -
Bayley, Alistair -
Scott Turner -
Simon Marlow