Vote count:
0
I've noticed that localtime seems to give different results on different platforms, despite the fact that every definition I can find seems to define it the same way.
I run the following code on Windows:
struct tm *tm1;
time_t ltime = (time_t)0;
tm1=localtime(<ime);
then edit, recompile and run the following:
struct tm *tm1;
time_t ltime = (time_t)60*60*24*30*6;
tm1=localtime(<ime);
The results are the same except for a difference of roughly 6 months and more importantly the following:
tm1.tm_hour = 00000000 //epoch
tm1.tm_hour = 00000001 //epoch + 6 months
This is expected since epoch (Jan 1st 1970) is not in daylight savings time for my timezone (GMT) but it has entered DST after 6 months. This demonstrates that Windows correctly applies DST rules.
However, when I do the same on Android I get:
tm1.tm_hour = 00000001 //epoch
tm1.tm_hour = 00000001 //epoch + 6 months
I have no idea why the results aren't consistent, this is surely about as simple as it gets! The only thing I can imagine is that, rather than applying DST rules, it is getting the localtime at epoch=0 for my current timezone, BST(GMT+1). Incidentally I've also done this on iOS, OSX and Linux, which also display the same problem as Android.
The clearest definition of localtime I can find seems to suggest that it should work as it does on Windows:
If an application uses localtime() to determine local time, localtime() will determine if daylight savings applies (assuming DST info is available) and will correctly set the tm_isdst flag.
tm_isdst is also stuck at 0 on the faulty platforms but changes on Windows, as it should.
Some obvious checks out the way:
- Timezone: All devices are currently set to the same timezone
- Hardware clocks: they seem synced but it shouldn't matter as I am passing in my own time value anyway, zero. localtime only requires the time value you pass in, the DST rules and the timezone according to TZ.
Aucun commentaire:
Enregistrer un commentaire