What experience do people have with handling dates/times in CL? I
noticed recently that SBCL signals errors when asked to
(decode-universal-time some-date-after-2038 nil). This is because,
despite mostly handling arbitrarily distant times as the spec
indicates it should, it uses the C library functions to lookup the
timezone, and they're limited to 32 bits since 1970.
On investigating further, I find that the binary timezone files that
the C library depends on (zonefiles based on David Olson's work) are
also using 32 bit integers to describe daylight savings transitions,
so reading the zonefiles directly wouldn't actually fix this. (It
would allow us an interface that's both sane and threadsafe though, so
retains a certain appeal even so). The source files are OK, but most
people don't have the source files installed already, so depending on
the Olson data would also mean distributing the Olson data. This is
an opportunity to create systems that have two inconsistent set of
rules for timezone calculations should this data change, of course.
Then we get onto the point that the CL standard expresses a timezone
as a simple offset to the UTC value, which doesn't seem sufficent to
describe the full story: how do you ask what the time in Arizona is?
(For other non-Americans, according to my reading of the timezone file
Arizona observes the same basic time offset as Denver, but doesn't
put clocks forward/back in summer as Denver does).
So, anyone doing complicated time calculations probably isn't doing
them with the CL standard representation anyway. On the one hand,
this makes me as an SBCL implementor feel less bad about the kludge
I'm probably about to add to deal with timezones after 2037 (assume
that all later years follow the same rules as 2036/2037 did) - it's
not going to affect anyone who really cares. On the other hand, I am
now wondering what these people _do_ use. I know about Erik Naggum's
'Long, Painful History of Time' paper
http://heim.ifi.uio.no/~enag/lugm-time.html
I'm not sure if the code this refers to was ever published (though I
notice that it parses the Olson binary data, so still suffers from
Y2038ness). Is anyone using it? Using something like it? Has a
completely different and equally good answer? What do programmers in
other languages do?
One very appealing but, I fear, politically impossible, solution is in
http://groups.google.com/groups?selm=3202619693677506%40naggum.net
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> (For other non-Americans, according to my reading of the timezone file
> Arizona observes the same basic time offset as Denver, but doesn't
> put clocks forward/back in summer as Denver does).
Most of Indiana is the same way. ISTR that there are some timezones
which are 30 minutes from "normal" zones (Newfoundland?).
--
Alan Shutko <···@acm.org> - I am the rocks.
Listen to your woman or you'll lose it all.
Daniel Barlow <···@telent.net> writes:
> (For other non-Americans, according to my reading of the timezone file
> Arizona observes the same basic time offset as Denver, but doesn't
> put clocks forward/back in summer as Denver does).
*Except* for parts of Arizona within the Navajo Reservation.
Fun, fun, fun!
--
··········@acm.org phone:+49-7031-464-7698 (TELNET 778-7698)
http://www.bawue.de/~jjk/ fax:+49-7031-464-7351
As the air to a bird, or the sea to a fish,
so is contempt to the contemptible. [Blake]
Jens Kilian <···········@agilent.com> writes:
> Daniel Barlow <···@telent.net> writes:
>> (For other non-Americans, according to my reading of the timezone file
>> Arizona observes the same basic time offset as Denver, but doesn't
>> put clocks forward/back in summer as Denver does).
>
> *Except* for parts of Arizona within the Navajo Reservation.
> Fun, fun, fun!
You know, when I posted the article I pretty much expected that a
great long thread would develop describing timezone idiocies such as
these and involving no reference to Lisp at all. So far two articles
does not constitute a great long thread, but it's still two articles
more than have addressed any of the Lisp-related points. ;-)
Let me try and bring this back on topic for c.l.l, by asking what time
conventions whales use.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> Jens Kilian <···········@agilent.com> writes:
>
> > Daniel Barlow <···@telent.net> writes:
> >> (For other non-Americans, according to my reading of the timezone file
> >> Arizona observes the same basic time offset as Denver, but doesn't
> >> put clocks forward/back in summer as Denver does).
> >
> > *Except* for parts of Arizona within the Navajo Reservation.
> > Fun, fun, fun!
>
> You know, when I posted the article I pretty much expected that a
> great long thread would develop describing timezone idiocies such as
> these and involving no reference to Lisp at all. So far two articles
> does not constitute a great long thread, but it's still two articles
> more than have addressed any of the Lisp-related points. ;-)
>
> Let me try and bring this back on topic for c.l.l, by asking what time
> conventions whales use.
This is really beyond the scope of CL, which while it has provisions for
people to move around dynamically (and not always be in the same time
zone) does NOT have a lot of provisions for being so big that you could
exist in multiple timezones at the same time. ;)
[Yeah, yeah, someone's going to cite the ability of even small people and
computers to stand on state lines... go ahead, spoil my joke...
Then you'll see some wailing...]
Kent M Pitman <······@world.std.com> writes:
> This is really beyond the scope of CL, which while it has provisions for
> people to move around dynamically (and not always be in the same time
> zone) does NOT have a lot of provisions for being so big that you could
> exist in multiple timezones at the same time. ;)
Nor does it have the ability to take Special Relativity into account.
Kent M Pitman <······@world.std.com> writes:
> This is really beyond the scope of CL, which while it has provisions for
> people to move around dynamically (and not always be in the same time
> zone) does NOT have a lot of provisions for being so big that you could
> exist in multiple timezones at the same time. ;)
OK, I know you said below that you're making a joke here, but I just
want to point out for anyone reading along at home that CL /is/ used
these days for server applications which may be simultaneously used by
people in different timezones (common example: a webmail system where
each user wants to see the date mail is received in their local time
zone) so there is actually a real application for getting this right.
> [Yeah, yeah, someone's going to cite the ability of even small people and
> computers to stand on state lines... go ahead, spoil my joke...
> Then you'll see some wailing...]
/me gnashes teeth
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> wrote:
> Jens Kilian <···········@agilent.com> writes:
>
>> Daniel Barlow <···@telent.net> writes:
>>> (For other non-Americans, according to my reading of the timezone file
>>> Arizona observes the same basic time offset as Denver, but doesn't
>>> put clocks forward/back in summer as Denver does).
>>
>> *Except* for parts of Arizona within the Navajo Reservation.
>> Fun, fun, fun!
>
> You know, when I posted the article I pretty much expected that a
> great long thread would develop describing timezone idiocies such as
> these and involving no reference to Lisp at all. So far two
> articles does not constitute a great long thread, but it's still two
> articles more than have addressed any of the Lisp-related points.
> ;-)
The thing is, the idiocies are things that have been discussed in
plenty enough gratuitous detail already.
I regularly see them when the software I work with reports time in
UTC, and people do idiotic transformations that typically lead them to
either:
a) Think time is off by 5 hours, or
b) For those that _think_ they have a clue, that all of the
data reported during daylight savings time is off by an hour,
because _they_ rounded it by an hour.
There are no particularly interesting Lisp issues; there's the obvious
problem that if you have to push datestamps into or out of Unix
filesystems, there is a risk of being off for dates way in the past or
future. If you're throwing timestamps through Windows, instead, the
range _might_ be a bit better, but by not using UTC, TAI, or some
other unambiguous time standard, things waver even more.
This should only be of great interest when manipulating file
timestamps, as that's the only persistent thing that needs to be
handled by the OS. And I don't see it being too likely that terribly
many filesystems present now will not have been reformatted well
before 2038. How many disk drives are likely to last 35 years?
--
output = reverse("gro.mca" ·@" "enworbbc")
http://cbbrowne.com/info/linuxy2k.html
Economists are still trying to figure out why the girls with the least
principle draw the most interest.