Hi again Mandeep,
Thanks for that.
> Accepted: 1446367200
> Ignorant of DST (-> 1): Sun Nov 1 01:40:00 2015
> Accepted: 1446370860
> Ignorant of DST (-> 0): Sun Nov 1 01:41:00 2015
OK, fun - now I know when at least one implementation changes over within the
hour !
Eddy.
Awesome! Glad I could help.
-mandeep
On Tue, Nov 17, 2015 at 5:40 AM, Welbourne Edward
wrote:
> Hi again Mandeep,
>
> Thanks for that.
>
>> Accepted: 1446367200
>> Ignorant of DST (-> 1): Sun Nov 1 01:40:00 2015
>> Accepted: 1446370860
>> Ignorant of DST
Hey Eddy,
Here's the response from my OSX 10.10.4 (Time Zone: Pacific Standard
Time (PST) -0800 UTC UTC/GMT).
$ ./mktime
Studying DST transitions in system default time-zone
Testing spring forward
Initial: Sun Mar 8 02:30:00 2015
Accepted: 1425810600
Ignorant of DST (-> 1): Sun Mar 8
> If you're willing to compile and run the attached simple C program,
> please let me know its output and your platform's details - ideally
> off-list - I'll give a summary in a few days' time.
Thanks to those who responded, I now know:
* that all the platforms below do the same thing if
On 3 November 2015 at 14:28, Welbourne Edward <
edward.welbou...@theqtcompany.com> wrote:
> Hi all,
>
> I'm looking into QTBUG-49008 and need to work out how diverse
> implementations of mktime handle DST transitions: at one end of the year
> there's a gap (where 1:59 is followed by 3:00), at the
On Thursday 05 November 2015 14:54:04 André Somers wrote:
> Interesting, I did not know that the summertime adjustment is
> synchronized in the EU. Interesting little factoid :-)
The sole purpose of this being, of course, to prevent you from speeding with
your car without penalty for more than
Op 5-11-2015 om 00:06 schreef Kevin Kofler:
Welbourne Edward wrote:
I'm looking into QTBUG-49008 and need to work out how diverse
implementations of mktime handle DST transitions: at one end of the year
there's a gap (where 1:59 is followed by 3:00), at the other end there's
a duplicated hour
Hi John,
I was hoping to hear from you - thanks for getting in touch.
> I'm the original author of a lot of the current QDateTime/QTimeZone code,
Indeed; git blame told me this and you'd shown up in my googling for
references to the topic, which is why I've added you to some
code-reviews.
>
Kevin Kofler wrote:
> The EU actually defines the switchover time in UTC,
That's a surprise. Do you have a reference for that ?
> so which hour is duplicated depends on the actual
> time zone. It's the 3:mm hour in CET/CEST.
I distinctly remember, the weekend before last, seeing the 2:mm hour
* André Somers [2015-11-05 13:10:33 +0100]:
> Op 5-11-2015 om 00:06 schreef Kevin Kofler:
> >Welbourne Edward wrote:
> >>I'm looking into QTBUG-49008 and need to work out how diverse
> >>implementations of mktime handle DST transitions: at one end of the year
> >>there's a
André Somers wrote:
> Actually, you are right about the sync in the EU (for all clocks) and
> about the hour that is duplicated depending on the time zone, but I
> think you are off on the hour it happens. In CET it is 2:mm that is
> duplicated, in GMT and WET it is 1:mm and in finland (EET) it is
On Thursday 05 November 2015 13:10:33 André Somers wrote:
> *) At least in so far the actual clock time in the country is concerned.
> Perhaps for other purposes the EU defines a single switchover moment for
> the whole of the EU? That is pure speculation though.
Correct. In Finland, the clocks
On Thursday 05 November 2015 08:45:01 Thiago Macieira wrote:
> On Thursday 05 November 2015 13:10:33 André Somers wrote:
> > *) At least in so far the actual clock time in the country is concerned.
> > Perhaps for other purposes the EU defines a single switchover moment for
> > the whole of the
Op 5-11-2015 om 00:06 schreef Kevin Kofler:
Welbourne Edward wrote:
I'm looking into QTBUG-49008 and need to work out how diverse
implementations of mktime handle DST transitions: at one end of the year
there's a gap (where 1:59 is followed by 3:00), at the other end there's
a duplicated hour
Welbourne Edward wrote:
> I'm looking into QTBUG-49008 and need to work out how diverse
> implementations of mktime handle DST transitions: at one end of the year
> there's a gap (where 1:59 is followed by 3:00), at the other end there's
> a duplicated hour (where 2:59 is followed by a reprise of
Hi all,
I'm looking into QTBUG-49008 and need to work out how diverse
implementations of mktime handle DST transitions: at one end of the year
there's a gap (where 1:59 is followed by 3:00), at the other end there's
a duplicated hour (where 2:59 is followed by a reprise of 2:00 in
Europe, or 1:59
16 matches
Mail list logo