I've almost been driven crazy with these DST riddles. Could you plese
take a glance at the following (CMUCL 19c)
Time zone Europe/Kiev, EET in winter, EEST in Summer
This year the Summer Time begins at 1:00 a.m. UT (3:00 EET) the last
Sunday in March, e.g. 26th March
* (- (encode-universal-time 0 0 4 26 3 2006) (encode-universal-time 0 0 3 26 3 2006))
0
so 0 is fine
The Summer Time ends at 1:00 a.m. UT (4:00 EEST) the last Sunday in
October, e.g. 29 October
* (- (encode-universal-time 0 0 3 29 10 2006) (encode-universal-time 0 0 4 29 10 2006))
-3600
don't think -3600 is right, do you?
Still less I can understand the follwing:
* (- (encode-universal-time 0 0 2 29 10 2006) (encode-universal-time 0 0 3 29 10 2006))
-7200
Could you throuh a little light on this?
--
Vladimir Zolotykh
Vladimir Zolotykh <······@eurocom.od.ua> writes:
> I've almost been driven crazy with these DST riddles. Could you plese
> take a glance at the following (CMUCL 19c)
> Time zone Europe/Kiev, EET in winter, EEST in Summer
>
> This year the Summer Time begins at 1:00 a.m. UT (3:00 EET) the last
> Sunday in March, e.g. 26th March
>
> * (- (encode-universal-time 0 0 4 26 3 2006) (encode-universal-time 0 0 3 26 3 2006))
>
> 0
> so 0 is fine
>
> The Summer Time ends at 1:00 a.m. UT (4:00 EEST) the last Sunday in
> October, e.g. 29 October
>
> * (- (encode-universal-time 0 0 3 29 10 2006) (encode-universal-time 0 0 4 29 10 2006))
>
> -3600
> don't think -3600 is right, do you?
>
> Still less I can understand the follwing:
>
> * (- (encode-universal-time 0 0 2 29 10 2006) (encode-universal-time 0 0 3 29 10 2006))
>
> -7200
>
> Could you throuh a little light on this?
2006-03-26
0 1 2 3
EET: |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|
4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
DST: |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|
2006-03-26 04:00:00 DST - 2006-03-26 03:00:00 EET = 0
2006-10-29
0 1 2 3
DST: |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
EET: |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|
2006-03-26 04:00:00 EET - 2006-03-26 03:00:00 DST = 2 hours.
--
__Pascal Bourguignon__ http://www.informatimago.com/
This universe shipped by weight, not volume. Some expansion may have
occurred during shipment.
Vladimir Zolotykh <······@eurocom.od.ua> writes:
> On Wed, 05 Apr 2006 14:56:33 +0200
> Pascal Bourguignon <······@informatimago.com> wrote:
>
>> Vladimir Zolotykh <······@eurocom.od.ua> writes:
>>
>> > I've almost been driven crazy with these DST riddles. Could you plese
>> > take a glance at the following (CMUCL 19c)
>> > Time zone Europe/Kiev, EET in winter, EEST in Summer
>> >
>> > This year the Summer Time begins at 1:00 a.m. UT (3:00 EET) the last
>> > Sunday in March, e.g. 26th March
>> >
>> > * (- (encode-universal-time 0 0 4 26 3 2006) (encode-universal-time 0 0 3 26 3 2006))
>> >
>> > 0
>> > so 0 is fine
>> >
>> > The Summer Time ends at 1:00 a.m. UT (4:00 EEST) the last Sunday in
>> > October, e.g. 29 October
>> >
>> > * (- (encode-universal-time 0 0 3 29 10 2006) (encode-universal-time 0 0 4 29 10 2006))
>> >
>> > -3600
>> > don't think -3600 is right, do you?
>> >
>> > Still less I can understand the follwing:
>> >
>> > * (- (encode-universal-time 0 0 2 29 10 2006) (encode-universal-time 0 0 3 29 10 2006))
>> >
>> > -7200
>> >
>> > Could you throuh a little light on this?
>>
>> 2006-03-26
>> 0 1 2 3
>> EET: |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|
>>
>> 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
>> DST: |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|
>>
>> 2006-03-26 04:00:00 DST - 2006-03-26 03:00:00 EET = 0
>>
>>
>> 2006-10-29
>> 0 1 2 3
>> DST: |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|
>>
>> 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
>> EET: |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|
>
> Is it correct ?
Yes. DST = EEST in your case.
> I'd think
>
> 2006-10-29
> 0 1 2 3 4
> EEST: |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|-
>
> 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
> EET: |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|-
This would be the same transition as in spring.
> (http://webexhibits.org/daylightsaving/b.html for example)
>
>> 2006-10-29
>> 0 1 2 3
>> DST: |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|
>>
>> 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
>> EET: |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|
>>
>> 2006-03-26 04:00:00 EET - 2006-03-26 03:00:00 DST = 2 hours.
I meant:
2006-10-29 04:00:00 EET - 2006-10-29 03:00:00 EEST = 2 hours.
> Let me emphasise. The difference in the two hours should be
>
> (- (encode-universal-time 0 0 4 29 10 2006)
> (encode-universal-time 0 0 3 29 10 2006))
>
> shouldn't it?
Sorry for the date, I meant 10 indeed. But your forms are inexact
too. Note that in the DST->Winter transition, the third and fourth
hours are labelled with the same numbers: from 3:00 to 4:00.
So (encode-universal-time 0 0 4 29 10 2006)
and (encode-universal-time 0 0 3 29 10 2006)
are really ambiguous.
You must specify the time zone you mean:
(- (encode-universal-time 0 0 4 29 10 2006 -2 #|EET = GMT+2|#)
(encode-universal-time 0 0 3 29 10 2006 -3 #|EEST = GMT+3|#))
--> 7200
Note the American-centric definition of time zone:
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.)
(Everybody else know that MA, USA is in time zone -5, not 5
http://www.worldtimezone.com/daylight.html
(Mind the labels above the time zone chart)).
The clock runs as:
2006-10-26 2:59:59 EEST
2006-10-26 3:00:00 EEST
2006-10-26 3:00:01 EEST
2006-10-26 ...
2006-10-26 3:59:58 EEST
2006-10-26 3:59:59 EEST
2006-10-26 3:00:00 EET
2006-10-26 3:00:01 EET
2006-10-26 ...
2006-10-26 3:59:58 EET
2006-10-26 3:59:59 EET
2006-10-26 4:00:00 EET
--
__Pascal Bourguignon__ http://www.informatimago.com/
PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this product, in any
manner whatsoever, will increase the amount of disorder in the
universe. Although no liability is implied herein, the consumer is
warned that this process will ultimately lead to the heat death of
the universe.
On Wed, 05 Apr 2006 16:25:28 +0200
Pascal Bourguignon <······@informatimago.com> wrote:
> Vladimir Zolotykh <······@eurocom.od.ua> writes:
>
> > On Wed, 05 Apr 2006 14:56:33 +0200
> > Pascal Bourguignon <······@informatimago.com> wrote:
> >
> >> Vladimir Zolotykh <······@eurocom.od.ua> writes:
> >>
> >> > I've almost been driven crazy with these DST riddles. Could you plese
> >> > take a glance at the following (CMUCL 19c)
> >> > Time zone Europe/Kiev, EET in winter, EEST in Summer
> >> >
> >> > This year the Summer Time begins at 1:00 a.m. UT (3:00 EET) the last
> >> > Sunday in March, e.g. 26th March
> >> >
> >> > * (- (encode-universal-time 0 0 4 26 3 2006) (encode-universal-time 0 0 3 26 3 2006))
> >> >
> >> > 0
> >> > so 0 is fine
> >> >
> >> > The Summer Time ends at 1:00 a.m. UT (4:00 EEST) the last Sunday in
> >> > October, e.g. 29 October
> >> >
> >> > * (- (encode-universal-time 0 0 3 29 10 2006) (encode-universal-time 0 0 4 29 10 2006))
> >> >
> >> > -3600
> >> > don't think -3600 is right, do you?
> >> >
> >> > Still less I can understand the follwing:
> >> >
> >> > * (- (encode-universal-time 0 0 2 29 10 2006) (encode-universal-time 0 0 3 29 10 2006))
> >> >
> >> > -7200
> >> >
> >> > Could you throuh a little light on this?
> >>
> >> 2006-03-26
> >> 0 1 2 3
> >> EET: |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|
> >>
> >> 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
> >> DST: |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|
> >>
> >> 2006-03-26 04:00:00 DST - 2006-03-26 03:00:00 EET = 0
> >>
> >>
> >> 2006-10-29
> >> 0 1 2 3
> >> DST: |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|
> >>
> >> 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
> >> EET: |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|
> >
> > Is it correct ?
>
> Yes. DST = EEST in your case.
>
>
> > I'd think
> >
> > 2006-10-29
> > 0 1 2 3 4
> > EEST: |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|-
> >
> > 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
> > EET: |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|-
>
> This would be the same transition as in spring.
I really don't see why this is wrong. 4:00 EEST becomes 3:00 EET,
Summer Time ends. Your chart in the end shows the same
> 2006-10-26 3:59:59 EEST
> 2006-10-26 3:00:00 EET
>
>
> > (http://webexhibits.org/daylightsaving/b.html for example)
> >
> >> 2006-10-29
> >> 0 1 2 3
> >> DST: |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|
> >>
> >> 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
> >> EET: |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|
> >>
> >> 2006-03-26 04:00:00 EET - 2006-03-26 03:00:00 DST = 2 hours.
> I meant:
> 2006-10-29 04:00:00 EET - 2006-10-29 03:00:00 EEST = 2 hours.
>
> > Let me emphasise. The difference in the two hours should be
> >
> > (- (encode-universal-time 0 0 4 29 10 2006)
> > (encode-universal-time 0 0 3 29 10 2006))
> >
> > shouldn't it?
>
> Sorry for the date, I meant 10 indeed. But your forms are inexact
> too. Note that in the DST->Winter transition, the third and fourth
> hours are labelled with the same numbers: from 3:00 to 4:00.
> So (encode-universal-time 0 0 4 29 10 2006)
> and (encode-universal-time 0 0 3 29 10 2006)
> are really ambiguous.
>
> You must specify the time zone you mean:
>
> (- (encode-universal-time 0 0 4 29 10 2006 -2 #|EET = GMT+2|#)
> (encode-universal-time 0 0 3 29 10 2006 -3 #|EEST = GMT+3|#))
> --> 7200
I'm not quite sure that we may use TIME-ZONE argument, because
"If time-zone is supplied, no adjustment for daylight savings time is
performed." according to HyperSpec, function ENCODE-UNIVERSAL-TIME
My original conviction was that as
(eql 0 (- (encode-universal-time 0 0 4 26 3 2006)
(encode-universal-time 0 0 3 26 3 2006)))
gives us true in Spring
(eql 7200 (- (encode-universal-time 0 0 4 29 10 2006)
(encode-universal-time 0 0 3 29 10 2006)))
must give us true in Autumn
>
> Note the American-centric definition of time zone:
>
> 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.)
>
> (Everybody else know that MA, USA is in time zone -5, not 5
> http://www.worldtimezone.com/daylight.html
> (Mind the labels above the time zone chart)).
>
>
> The clock runs as:
>
> 2006-10-26 2:59:59 EEST
> 2006-10-26 3:00:00 EEST
> 2006-10-26 3:00:01 EEST
> 2006-10-26 ...
> 2006-10-26 3:59:58 EEST
> 2006-10-26 3:59:59 EEST
> 2006-10-26 3:00:00 EET
> 2006-10-26 3:00:01 EET
> 2006-10-26 ...
> 2006-10-26 3:59:58 EET
> 2006-10-26 3:59:59 EET
> 2006-10-26 4:00:00 EET
>
>
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this product, in any
> manner whatsoever, will increase the amount of disorder in the
> universe. Although no liability is implied herein, the consumer is
> warned that this process will ultimately lead to the heat death of
> the universe.
--
Vladimir Zolotykh
Vladimir Zolotykh <······@eurocom.od.ua> writes:
>> > I'd think
>> >
>> > 2006-10-29
>> > 0 1 2 3 4
>> > EEST: |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|-
>> >
>> > 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
>> > EET: |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|-
>>
>> This would be the same transition as in spring.
>
> I really don't see why this is wrong. 4:00 EEST becomes 3:00 EET,
> Summer Time ends.
No.
By law (check with your lawyer), when you have 4:00 EEST = 3:00 EET,
it's the spring transition, from EET to EEST, when Super Time BEGINS.
Equality is symetric, but the transition is from EET to EEST, not in
the other direction.
In March, 3:00 EET ---> 4:00 EEST, begins summer time;
In October, 4:00 EEST ---> 3:00 EET, ends summer time.
> Your chart in the end shows the same
Compare again!
>> >> 2006-10-29
>> >> 0 1 2 3
>> >> EEST: |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|
>> >>
>> >> 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
>> >> EET: |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|
>> You must specify the time zone you mean:
>>
>> (- (encode-universal-time 0 0 4 29 10 2006 -2 #|EET = GMT+2|#)
>> (encode-universal-time 0 0 3 29 10 2006 -3 #|EEST = GMT+3|#))
>> --> 7200
>
> I'm not quite sure that we may use TIME-ZONE argument, because
> "If time-zone is supplied, no adjustment for daylight savings time is
> performed." according to HyperSpec, function ENCODE-UNIVERSAL-TIME
If you want to know the universal time of 3:00, then don't use the
time zone argument.
If you want to know the univeral time of 3:00 EET, then you must give
it the time zone argument (and you have to know that EET = GMT+2,
therefore time-zone = -2).
> My original conviction was that as
>
> (eql 0 (- (encode-universal-time 0 0 4 26 3 2006)
> (encode-universal-time 0 0 3 26 3 2006)))
>
> gives us true in Spring
>
> (eql 7200 (- (encode-universal-time 0 0 4 29 10 2006)
> (encode-universal-time 0 0 3 29 10 2006)))
>
> must give us true in Autumn
I cannot say, since on 2006-10-29, it's 3:00:00 twice and it's 4:00:00 twice.
It's 3:00:00 once at 3:00 EEST, and once at 4:00 EEST, when it's 3:00 EET.
It's 4:00:00 once at 4:00 EEST when it's 3:00 EET, and once at 4:00 EET.
Now, read again CLHS, and tell me what it has to say about it!
"If time-zone is supplied, no adjustment for daylight savings time is performed."
What does this mean?
Now, we are in DST.
Does this mean that:
(- (encode-universal-time 0 0 0 4 4 2006)
(encode-universal-time 0 0 0 1 1 2006))
will give a multiple of 24 hours, because no adjustment for the
daylight savings time we have now is performed?
Now we are in DST.
Does this mean that:
(- (encode-universal-time 0 0 4 29 10 2006)
(encode-universal-time 0 0 3 29 10 2006))
should be computed considering EET because no adjustment for the
daylight savings time we have now is performed, therefore it should
reverse the adjustement for DST from EET?
Or does this mean that:
(- (encode-universal-time 0 0 4 29 10 2006)
(encode-universal-time 0 0 3 29 10 2006))
should be computed considering EEST because no adjustment for the
daylight savings time we have now is performed, therefore it shouldn't
reverse the adjustement for DST from EET (which itself would be an
adjustement)?
Or does this mean that:
(- (encode-universal-time 0 0 4 29 10 2006)
(encode-universal-time 0 0 3 29 10 2006))
should be computed one with EEST and the other with EET? This surely
is not possible because some adjustement for DST would be done in one
or the other case.
It's absolutely impossible to get 7200 for this expression. You need
to specify which time zone you're considering.
> [...]
Read again this:
>> The clock runs as:
>>
>> 2006-10-26 2:59:59 EEST
>> 2006-10-26 3:00:00 EEST
>> 2006-10-26 3:00:01 EEST
>> 2006-10-26 ...
>> 2006-10-26 3:59:58 EEST
>> 2006-10-26 3:59:59 EEST
>> 2006-10-26 3:00:00 EET
>> 2006-10-26 3:00:01 EET
>> 2006-10-26 ...
>> 2006-10-26 3:59:58 EET
>> 2006-10-26 3:59:59 EET
>> 2006-10-26 4:00:00 EET
--
__Pascal Bourguignon__ http://www.informatimago.com/
THIS IS A 100% MATTER PRODUCT: In the unlikely event that this
merchandise should contact antimatter in any form, a catastrophic
explosion will result.
Vladimir Zolotykh <······@eurocom.od.ua> writes:
> On Wed, 05 Apr 2006 17:28:54 +0200
> Pascal Bourguignon <······@informatimago.com> wrote:
>
>> >> You must specify the time zone you mean:
>> >>
>> >> (- (encode-universal-time 0 0 4 29 10 2006 -2 #|EET = GMT+2|#)
>> >> (encode-universal-time 0 0 3 29 10 2006 -3 #|EEST = GMT+3|#))
>> >> --> 7200
>
> Is the result of
>
> (nth-value 7 (decode-universal-time
> (encode-universal-time 0 0 3 29 10 2006)))
>
> implementation dependant?
Note, ENCODE-UNIVERSAL-TIME says:
If time-zone is supplied, no adjustment for daylight savings time is
performed.
and DECODE-UNIVERSAL-TIME says:
If time-zone is not supplied, it defaults to the current time zone
adjusted for daylight saving time.
and:
Affected By:
Implementation-dependent mechanisms for calculating when or if
daylight savings time is in effect for any given session.
So, first, it's not too wise to convert to and from once with DST
adjustement, once without: in anycase, it could only tell you if DST
is currently active or not, nothing about the date you give as
parameter.
But to answer to your question, yes, it's implementation dependant.
Note that an implementation would be allowed to determine at the start
of a session whether DST applies, once for the whole session. When
you have a lisp session running for months, DECODE-UNIVERSAL-TIME
could apply or not DST beyond the DST transition. Eg, the result of:
(encode-universal-time 0 0 3 29 10 2006) ; or any other date, may
depend on the time at which it is executed, may change from one time
to the other in some implementation or not.
(- (encode-universal-time 0 0 3 29 10 2006)
(progn (sleep 1)
(encode-universal-time 0 0 3 29 10 2006)))
may be always 0, or sometimes 0 and sometimes not 0.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NEW GRAND UNIFIED THEORY DISCLAIMER: The manufacturer may
technically be entitled to claim that this product is
ten-dimensional. However, the consumer is reminded that this
confers no legal rights above and beyond those applicable to
three-dimensional objects, since the seven new dimensions are
"rolled up" into such a small "area" that they cannot be
detected.