It seems the optional time-zone parameter in (encode-universal-time)
has to be an integer.
But what can I do with a date whose timezone offset is fractional,
e.g. "GMT +5:30" ?
dpapathanasiou <···················@gmail.com> writes:
> It seems the optional time-zone parameter in (encode-universal-time)
> has to be an integer.
Not true; it has to be a rational. The glossary says this:
time zone n. a rational multiple of 1/3600 between -24 (inclusive)
and 24 (inclusive) that represents a time zone as a number of hours
offset from Greenwich Mean Time. Time zone values increase with
motion to the west, so Massachusetts, U.S.A. is in time zone 5,
California, U.S.A. is time zone 8, and Moscow, Russia is time zone
-3. (When ``daylight savings time'' is separately represented as an
argument or return value, the time zone that accompanies it does not
depend on whether daylight savings time is in effect.)
> But what can I do with a date whose timezone offset is fractional,
> e.g. "GMT +5:30" ?
Use a fraction like -11/2.
Zach
On Aug 14, 9:16 am, Zach Beane <····@xach.com> wrote:
> dpapathanasiou <···················@gmail.com> writes:
> > It seems the optional time-zone parameter in (encode-universal-time)
> > has to be an integer.
>
> Not true; it has to be a rational. The glossary says this:
>
> time zone n. a rational multiple of 1/3600 between -24 (inclusive)
> and 24 (inclusive) that represents a time zone as a number of hours
> offset from Greenwich Mean Time. Time zone values increase with
> motion to the west, so Massachusetts, U.S.A. is in time zone 5,
> California, U.S.A. is time zone 8, and Moscow, Russia is time zone
> -3. (When ``daylight savings time'' is separately represented as an
> argument or return value, the time zone that accompanies it does not
> depend on whether daylight savings time is in effect.)
>
> > But what can I do with a date whose timezone offset is fractional,
> > e.g. "GMT +5:30" ?
>
> Use a fraction like -11/2.
Thanks.
dpapathanasiou <···················@gmail.com> writes:
> It seems the optional time-zone parameter in (encode-universal-time)
> has to be an integer.
>
> But what can I do with a date whose timezone offset is fractional,
> e.g. "GMT +5:30" ?
It seems you need to read more CLHS ;-) In particular,
decode-universal-time gives you a link to the glossary:
time zone n. a rational multiple of 1/3600 between -24 (inclusive) and
24 (inclusive) that represents a time zone as a number of hours offset
from Greenwich Mean Time. Time zone values increase with motion to the
west, so Massachusetts, U.S.A. is in time zone 5, California,
U.S.A. is time zone 8, and Moscow, Russia is time zone -3. (When
``daylight savings time'' is separately represented as an argument or
return value, the time zone that accompanies it does not depend on
whether daylight savings time is in effect.)
So if you can't use a "fractional" at least you can use a rational here.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
* Pascal Bourguignon <··············@thalassa.informatimago.com> :
|> But what can I do with a date whose timezone offset is fractional,
|> e.g. "GMT +5:30" ?
|
| It seems you need to read more CLHS ;-) In particular,
| decode-universal-time gives you a link to the glossary:
|
| time zone n. a rational multiple of 1/3600 between -24 (inclusive) and
| 24 (inclusive) that represents a time zone as a number of hours offset
| from Greenwich Mean Time. Time zone values increase with motion to the
| west, so Massachusetts, U.S.A. is in time zone 5, California,
| U.S.A. is time zone 8, and Moscow, Russia is time zone -3. (When
| ``daylight savings time'' is separately represented as an argument or
| return value, the time zone that accompanies it does not depend on
| whether daylight savings time is in effect.)
|
| So if you can't use a "fractional" at least you can use a rational here.
I recently had an implementation barf at me when I passed in a NIL as
the timezone: for example:
(decode-universal-time (get-universal-time) nil)
while expecting it to give me the implementation specific behaviour. The
behaviour is consistent with CLHS bit quoted above which says timezone
should be a rational. However The function signature says:
decode-universal-time (utime &optional (timezone nil tz-p))
Now, the problem is in writing wrappers around the universal-time
functions: I have to modify each call site: For example I cannot write
(defun foo (&optional tz)
...
(decode-universal-time x tz)
...)
But need to explicitly write two calls:
(defun foo (&optional (timezone nil tz-p))
...
(if tz-p
(decode-universal-time x tz)
(decode-universal-time x))
...)
A few weeks ago there was the thread `calling function with default
arguments' which dealt with defaulting &key arguments. But I don't
think there is any cute solution for &optionals which suffer this
problem. Is there?
--
Madhu
Madhu <·······@meer.net> writes:
> * Pascal Bourguignon <··············@thalassa.informatimago.com> :
> |> But what can I do with a date whose timezone offset is fractional,
> |> e.g. "GMT +5:30" ?
> |
> | It seems you need to read more CLHS ;-) In particular,
> | decode-universal-time gives you a link to the glossary:
> |
> | time zone n. a rational multiple of 1/3600 between -24 (inclusive) and
> | 24 (inclusive) that represents a time zone as a number of hours offset
> | from Greenwich Mean Time. Time zone values increase with motion to the
> | west, so Massachusetts, U.S.A. is in time zone 5, California,
> | U.S.A. is time zone 8, and Moscow, Russia is time zone -3. (When
> | ``daylight savings time'' is separately represented as an argument or
> | return value, the time zone that accompanies it does not depend on
> | whether daylight savings time is in effect.)
> |
> | So if you can't use a "fractional" at least you can use a rational here.
>
>
> I recently had an implementation barf at me when I passed in a NIL as
> the timezone: for example:
> (decode-universal-time (get-universal-time) nil)
>
> while expecting it to give me the implementation specific behaviour.
But barfing is the implementation specific behavior!
> The behaviour is consistent with CLHS bit quoted above which says
> timezone should be a rational. However The function signature says:
> decode-universal-time (utime &optional (timezone nil tz-p))
Well, the exact signature is not specified, only:
decode-universal-time universal-time &optional time-zone
The default value, and whether there is a presence indicator is to be
considered as an implementation detail.
On the other hand, timezone is specified to be a time zone, which is
defined to be a rational multiple of 1/3600 between -24 (inclusive)
and 24 (inclusive), which doesn't include NIL.
Therefore indeed, (decode-universal-time utime NIL) is not portable
code, and may have in a given implementation the only effect of
signaling an error.
> Now, the problem is in writing wrappers around the universal-time
> functions: I have to modify each call site: For example I cannot write
>
> (defun foo (&optional tz)
> ...
> (decode-universal-time x tz)
> ...)
>
> But need to explicitly write two calls:
>
> (defun foo (&optional (timezone nil tz-p))
> ...
> (if tz-p
> (decode-universal-time x tz)
> (decode-universal-time x))
> ...)
>
> A few weeks ago there was the thread `calling function with default
> arguments' which dealt with defaulting &key arguments. But I don't
> think there is any cute solution for &optionals which suffer this
> problem. Is there?
Or:
(apply (function decode-universal-time) x (when tz-p (list timezone)))
which might be easier when there are several optional or keyword
arguments to combine.
Another option is to pass a valid parameter, but indeed, there may be
a difference. In the case of decode-universal-time, if you pass as
parameter a rational representing the current local time zone, you
don't get the daylight savings processing (since you have an
"absolute" time zone).
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.