Week View

Ah, yes. It is... I'll look at it this weekend!

Thank you for the feedback :)

Update on this: I have not had the time to work on it, because of school, and spending my time on porting the 6.x-2.x branch. That's now in beta, so I will focus on this next.

This is now fixed in dev. Please give feedback on how this works.

I'm try 7.x-1.1 version.
I see wrorng week day. Please see screenshot.

Aha, I think it's because of the time zone difference for the forecast. The day name is taken from the first box under the name, but because of the time zone difference (and/or daylight saving time) the first box is set to 23:00 the day before on your server (from yr.no, it's 00:00 the next day).

I have to prioritize school this weekend, but I'll take a look at it later next week.

I hope I have managed to fix this now. Committed to CVS, should show up in a nightly snapshot (after the cvs -> git migration?)

I test last dev version. Please see screenshot.

Ok. That's actually correct, but the time for the boxes is one hour wrong. I think it could be because of Daylight Savings Time or something.
The boxes you have marked are in their right place, but the time is one hour backwards.

Can you check what date and timezone settings your server is running?

Please see screenshot

And this screenshots

Hello again. The module actually works correctly now, but the time from yr.no is set to what you see.

• In forecast5.png, period 0 shows 03.03.2011 - 2300, and period 1 shows 04.03.2011 - 0500.
• In forecast6.png, period 0 is not shown, and period 1 shows 04.03.2011 - 0500.

The date and time shown is the same as in the xml. The problem is that for some locations (like yours), yr.no delivers period 0 with the time set to 23:00 the day before. On "standard" locations, period 0 is set to 00:00 at the day we expect it to be.

This seems to only be a problem with some locations (Central Asia, Hawaii...)

I don't really have any good suggestions for this problem, because this problem is not valid for all locations, and I can't think of any good solutions for managing this?

I also get this issue and was puzzled by it.

I thought first it was an styling issue with yr-longterm-day that forced the flow of boxes to wrap at maximum four items, but this was not the case. In my case one of the locations, Tokyo, is displaying forecasts five times a day in the nearest future and than four times a day thereafter. I belive this could be ficxed by alowing for more than four times a day before yr-longterm-day closes the row of boxes.

I may have understood this problem all wrong, if so I'm happy to be enlightened. Image attached

Hello there. I see that you have a similar, yet different screenshot from the previous. I will work on this some more, but I can't promise a quick fix, because of all the different server set ups and other factors that exist, combined with how the date and time is delivered from yr.no. But I'll continue working on it :)

Tanks for quick reply!

Maybe by closing the yr-longterm-day between the increase in day from the output could be done. As I understand you this problem occur because the input is moved/converted in time(zone/daylight-saving) before being written out for display. Is it so? - though some countries does not add/remove an hour for daylight saving which may explain that 00:00 local time may falsely become 23:00 the day before for instans-, I don't know.

I have made another attempt at fixing this, but I expect it to not work on some configurations. Should be in the next dev snapshot.

The solution in #15 is perhaps a possibility, but I'm not sure if that will work on all setups either. Will take a look, but this is not a priority.

subscribe

This issue is still a problem, but only for some locations. I got some of the "wrong" times from yr.no, so it might be really hard to get a proper fix for it. Leaving it open for now, in case others are looking for answers to the same question.