You are here

Unix time (midnight in GMT)

10 posts / 0 new
Last post
doglover
Offline
Joined: 11 years
Last seen: 2 years
Unix time (midnight in GMT)

For requesting the schedule of FilmEurope I need the Unix time of Midnight in GMT.
I solved it this way:

urldate.format {datestring|yyyy-MM-dd}
index_variable_element.modify {calculate(scope=urlindex format=date,unix)|'urldate' 00:02 -}
url_index.modify {replace(scope=urlindex)|xxxxxxxx|'index_variable_element'}

But of course each time DST kicks-in, I have to change the hours substracted.
Can I solve this in an other way?

PS: the schedule is in the tmezone Europe/Paris, so I cannot set the timezone to GMT

Blackbear199
Offline
Blackbear199's picture
WG++ Team memberDonator
Joined: 8 years
Last seen: 3 hours

thats the only way unless u happen to be running webgrab from a pc/server thats using the same time offset(timezone).

from what i seen looking at the site,GMT time isnt ur problem,ist the site wants the date(url_undex line) either 1 hr(no DST) or 2 hr(DST) before GMT.

if the above happens to be true u can do this to get the time current time offset from UTC

element.modify {calculate(format=date,zzz)|'now'}

so if the pc/server were in the same timezone it would return +02:00 right now or +01:00 when DST ends.

u cant do
element.modify {calculate(format=date,zzz)|'urldate'}

the input is just a raw date string so it will return the same result as using 'now'(offset of pc/server timezone setting)

there is another trick u cud do also.

use a simple bat or sh file and get the time offset for the timezone u want.u can call a external file using set(type=run)

doglover
Offline
Joined: 11 years
Last seen: 2 years
Blackbear199 wrote:

the site wants the date(url_undex line) either 1 hr(no DST) or 2 hr(DST) before GMT.

That is exactly what it is.

The trick with the run option, is more trouble than it is worth.
Besides I have run the script on both linux and windows.

Looking into the other now.

doglover
Offline
Joined: 11 years
Last seen: 2 years

Solved:

scope.range {(urlindex)|end}
global_temp_1.modify { calculate (format=date,zzz)|'urldate'}
global_temp_1.modify {replace()|+|00:}
index_variable_element.modify {calculate(format=date,unix)|'urldate' 'global_temp_1' -}
url_index.modify {replace(scope=urlindex)|xxxxxxxx|'index_variable_element'}
end_scope
*

So a bit more statements neede.

Blackbear199
Offline
Blackbear199's picture
WG++ Team memberDonator
Joined: 8 years
Last seen: 3 hours

as i said the only reason it worked is because the pc/server running webgrab is in the same timezone.

global_temp_1.modify { calculate (format=date,zzz)|'urldate'}
when this performed wg dont know what timezone its in so it uses the timeoffset of the pc/server its run on.

when i do the same its wrong..

[ Debug ] command & arguments : calculate (debug format=date,zzz)
[ Debug ] Expression-1 : 'urldate'
[ Debug ] Element value before operation:
[ Debug ] empty element before the operation!
[ Debug ] String composer result for Expression-1 :
[ Debug ] Expression-1 expanded : 636896736000000000>>
[ Debug ] Element value after operation:
[ Debug ] -03:00

-03:00 is my local time offset.

so if u ran ur ini on any pc/server with a different timezone than the one needed it will not work.

doglover
Offline
Joined: 11 years
Last seen: 2 years

OK. I understand. Luckily I am in the same timezone.

With a bit more work, it can made universal I think.
1. Calculate the difference of your timezone with the timezone the website wants. In my case it is 0 h in your case it is +1h (depending if you have DST in the place where you live - do not tell me)
2. Subtract this from the timezone obtained from the statement
3. Now subtract this from the time 'urldate'

But again: how to determine the value in point 1 automatically.
But now, the adaptation should only take place one time. Not with every DST change.

These DST changes make live diffecult

Blackbear199
Offline
Blackbear199's picture
WG++ Team memberDonator
Joined: 8 years
Last seen: 3 hours

starting next yr europe is doing away with DST i believe.
here's how it can be done and shud always get it correct(i think)..

urldate.format {datestring|dd-MM-yyyy}

scope.range{(urlindex)|end}
global_temp_1.modify {calculate(format=date,unix)|'urldate'}
global_temp_2.modify {calculate(format=utcdate,unix)|'urldate'}
global_temp_3.modify {calculate(format=F0)|'global_temp_2' 'global_temp_1' - 60 /}
global_temp_3.modify {calculate(format=timespan,days)}
global_temp_4.modify {calculate(debug format=date,unix)|'urldate' 'global_temp_3' -}
url_index.modify {replace|##unixdate##|'global_temp_4'}
end_scope

or it can also be dont using the timezone= calculation feature but involves more steps..

scope.range{(urlindex)|end}
global_temp_1.modify {calculate(format=date,unix)|'urldate'}
global_temp_2.modify {set|'global_temp_1'}
global_temp_2.modify {calculate(timezone=UTC)}
global_temp_2.modify {calculate(format=date,unix)}
global_temp_3.modify {calculate(debug format=F0)|'global_temp_2' 'global_temp_1' - 60 /}
global_temp_3.modify {calculate(format=timespan,days)}
global_temp_4.modify {calculate(format=date,unix)|'urldate' 'global_temp_3' -}
url_index.modify {replace|##unixdate##|'global_temp_4'}
end_scope

this is with 2.1.7 or above,2.1.5 and below would calculate the timespans,days incorrectly,it would return 2 days instead of hours so this would have to be changed again for it.

for 2.1.5 and below these changes are needed..

global_temp_3.modify {calculate(format=timespan,hours)}
global_temp_4.modify {calculate(debug format=date,unix)|'urldate' 0:'global_temp_3' -}

mat8861
Offline
WG++ Team memberDonator
Joined: 8 years
Last seen: 17 hours

Well if tzdata will be updated next year no need to do all that. The recent update is ok though, hopefully EU will change to no DST for ever. That is the good part of updates, but temporarly BB solution is the best.

doglover
Offline
Joined: 11 years
Last seen: 2 years

I will only believe that DST time changes are a thing of the past, when it is decided.
As it stands now, it will be some time before that happens. The discussion is to which timezone should we go. Permanent Wintertime of permanent Summertime.
The discussion is continuing, and I believe it will go on for some time.

This does not take away from the fact that I believe that DST should be abolished.

doglover
Offline
Joined: 11 years
Last seen: 2 years

Tested the code from BB and added to the SiteIni.
(Added BB to the credits)
Works both in 2.1.4 and 2.1.8 - At least in my timezone

Log in or register to post comments

Brought to you by Jan van Straaten

Program Development - Jan van Straaten ------- Web design - Francis De Paemeleere
Supported by: servercare.nl