Re: [Development] How does mktime() handle DST transitions ?

2015-11-17 Thread Welbourne Edward
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.

Re: [Development] How does mktime() handle DST transitions ?

2015-11-17 Thread Mandeep Sandhu
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

Re: [Development] How does mktime() handle DST transitions ?

2015-11-16 Thread Mandeep Sandhu
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

Re: [Development] How does mktime() handle DST transitions ?

2015-11-06 Thread Welbourne Edward
> 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

Re: [Development] How does mktime() handle DST transitions ?

2015-11-05 Thread John Layt
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

Re: [Development] How does mktime() handle DST transitions ?

2015-11-05 Thread Marc Mutz
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

Re: [Development] How does mktime() handle DST transitions ?

2015-11-05 Thread André Somers
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

Re: [Development] How does mktime() handle DST transitions ?

2015-11-05 Thread Welbourne Edward
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. >

Re: [Development] How does mktime() handle DST transitions ?

2015-11-05 Thread Welbourne Edward
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

Re: [Development] How does mktime() handle DST transitions ?

2015-11-05 Thread Florian Bruhin
* 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

Re: [Development] How does mktime() handle DST transitions ?

2015-11-05 Thread Kevin Kofler
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

Re: [Development] How does mktime() handle DST transitions ?

2015-11-05 Thread Thiago Macieira
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

Re: [Development] How does mktime() handle DST transitions ?

2015-11-05 Thread Thiago Macieira
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

Re: [Development] How does mktime() handle DST transitions ?

2015-11-05 Thread André Somers
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

Re: [Development] How does mktime() handle DST transitions ?

2015-11-04 Thread 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 (where 2:59 is followed by a reprise of

[Development] How does mktime() handle DST transitions ?

2015-11-03 Thread Welbourne Edward
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