Daylight saving time for cpg1.5.x

[Αndré]

Switches the gallery to daylight saving time. This plugin has <strong>no</strong> configuration. Your gallery is set to daylight saving time immediately after plugin installation. After deinstallation your gallery is automatically set to standard time.

[Joachim Müller]

Hm, no offence, but what's the use of this plugin if it doesn't take care of DST automatically? If you have to remember the date to turn it on and off and have to access the plugin manager and install/uninstall the plugin on that date, what would be the benefit? You could just as well go to Coppermine's config and change the time offset there.

To turn this into a really usefull plugin you would have to add a table (a simplified version of http://www.timeanddate.com/time/dst2010.html ff.) where all the dates are being kept on which the DST will be turned on/off for the next few years. Remember that this differs from country to country, so you'll have to provide a plugin config option to specify the country the user is in. We wouldn't want to run a query against that table though each time the script is being accessed, so we'd have to apply some caching mechanism. The best way to deal with this would be storing the next date when the time needs to be re-adjusted within an additional config field (something like plugin_dst_date) and only trigger the repopulation of that field once with a separate function that only get's executed once per DST change.
The plugin itself would then be triggered by something that happens each day (the page_start action is fine), but it would have to check if we're currently in the DST period for the country initially specified and if yes add another hour to the time offset as you currently do.

Bottom line: I would find this helpfull if it could work automatically and would like to see this implemented in a future version of Coppermine inside the core. If you agree I can come up with a draft how I would accomplish what I suggested above.

Cheers

Joachim

[Αndré]

I mainly created that plugin because I saw a checkbox in another application that switched that application to dst/standard time (I think it was phpBB). I agree, that it would also be possible to adjust the time offset. But I think if you live in e.g. GMT+1, you shouldn't set it to GMT+2 if it's daylight saving time. Some people (like me, especially when I'm tired ) have to think about in which direction you have to adjust the offset.

I didn't thought about an automatic adjustment yet. But it's a good idea, so consider version 1.0 as a first draft

Feel free to create a draft of the automatic adjustment (it has to be done anyway, if we want to to add it to the core of a future version of Coppermine). But I'm currently happy how the plugin works

[Albe]

I hope I am allowed to put here a translation of the 7374-plugins-dst-lang-english.php into dutch?
for what it's worth, see attach.

[Αndré]

Thanks for your contribution. Added Dutch language file in r7381.

[Joachim Müller]

Whew, this has turned out to be more complicated than I originally thought . I have adopted the plugin to work as I suggested above. As a proof of concept I have refrained from the use of a database table to hold all the time zone information that will be used only once in a while and only for lookup purposes. Instead, I have put the data into an xml file. The xml data need adding (so far only European locations and some more countries have been added), so please consider this a work-in-progress. That's why I haven't created a downloadable package yet, but those who want to take a peak are welcome to check out the subversion repository.

[phill104]

Hmm, I saw some code a few weeks back that checks your location from your computer then reads the time from one of the many BBC time sources automatically correcting for local DST etc. I wonder if that would be a little more useful?

[Joachim Müller]

PHP5 has much more efficient tools for time zone management, but PHP4 lacks them. If we should agree one day to raise the minimum requirement level for cpg to PHP5 I'm all ears for another way to do this server-sided.
But then again no, the most sophisticated tool on your server won't help, as the place where the server is located doesn't have to be the place where the site owner and his target audience are located. It doesn't help if I sign up with a webhosting company who have their servers located in the US when I try to catter for a German audience; I want the application's time and DST zone to be the one of Germany of course. I understand that you're proposing something else: a push of the time zone of the web site admin's client time zone to the server. Sounds interessting, but I'm not sure if this works in all environments, as there is little in the PHP variables that we could use, so we would have to rely on JavaScript gimmicks or (even worse) OS-dependant tricks (afaik .NET has got some nice tricks for this, but then: wo is using .NET? ). Anyway, I would really like to see the code you propose, maybe it can do this much more efficiently; if not now for the plugin, maybe in the future for the core.

[Αndré]

Good job so Joachim. I committed some minor changes in r7452.

[Albe]

Good job so Joachim. I committed some minor changes in r7452.

I've translated (/dst/lang/dutch.php) and installed this (r7452) new version in my testbed but have seen a problem in te theme "Curve" with the language-file.

If I let the languagefile (/dst/lang/dutch.php) in 'ANSI' everything works exept for the accented characters.
(see attach 2)

If I convert the languagefile (/dst/lang/dutch.php) into 'utf8' there's something wrong with the menustructure but the accented characters are OK.
(see attach 3)

My computer Operating System: Windows 7, Ultimate, 64-bit
Internet Explorer 8
Temporary Testbed with "normal curve" as standard : http://espero-home.net/Test/cfg/
User: Tester
password: fonteintje


My testbed with adapted colors for "Curve":  http://fonteintje-diepenbeek.net/Fotoalbum/index.php

[Αndré]

Can you please attach the language file? Thank you.

[Αndré]

I just found it here

[Albe]

Can you please attach the language file? Thank you.

It is also in the first attach!

[Αndré]

there's something wrong with the menustructure

I cannot reproduce that behavior. I removed the BOM from your language file. Please try the Dutch language file of r7457.

[Albe]

I cannot reproduce that behavior. I removed the BOM from your language file. Please try the Dutch language file of r7457.

Thank you very much! (I think it solved even other little problems I've had.)

You're right! It was the "bom" causing the "explosion"!  

See attach 1 (utf8 with BOM) the menustructure is wrong, the accented karakters are good
See attach 2 (utf8 without BOM) the menustructure and the accented karakters are good

Maybe just a suggestion:
I've read in the docs (http://documentation.coppermine-gallery.net/nl/translation.htm#translation_char_encoding) about translation and found this:

You'll have noticed that coppermine language files come in utf-8 encoding. You do not have to concern yourself with the creation of the utf-8 version if you have no idea how to accomplish this - the dev team will take care of that. However, your language file will finally go into the package as UTF-8 file. Subsequently, if you want to create a perfect language file, create it in utf-8 in the first place.

Here's nothing about the "BOM"-code
(I know what the "BOM"-code means, but didn't think of because in the svn are different files in the /lang/-directory: ANSI, utf8 with and without bom).
In Coppermine it seemes to be so important that it's maybe worth to be mentioned also in this text?

[Joachim Müller]

I've read in the docs ( http://localhost:8080/gal/docs/nl/translation.htm#translation_char_encoding)

There's little sense in refering to your local files. a really usefull link would be http://documentation.coppermine-gallery.net/nl/translation.htm#translation_char_encoding

The English language files indeed are in iso8859-1 / ANSI, which is of course silly and making it harder for translators, however there seem to be issues with some editors that needs looking into first. Please stand by.

[Albe]

There's little sense in refering to your local files. a really usefull link would be http://documentation.coppermine-gallery.net/nl/translation.htm#translation_char_encoding

Thanks! Ofcourse you are right. I 've just forgotten that for easier reading I've put a copy of the whole documentation on my local machine.

The English language files indeed are in iso8859-1 / ANSI, which is of course silly and making it harder for translators, however there seem to be issues with some editors that needs looking into first. Please stand by.

I'm using most of the time "Notepad++" to edit flat files and "Total Commander 7.50" to compare files.

For now it's good to know that "to BOM or not to BOM"    can have such a drastic influance on some parts of the layout.
I'm very happy, even as a retired "old" man,  I can learn every day new things!

[Αndré]

The English language files indeed are in iso8859-1 / ANSI

My preferred editor is Notepad++. If I try to save a text file with only ANSI characters as UTF-8 without BOM and reload that file, my editor shows that file as ANSI encoded. That's not surprising, as there is no difference between that files and I assume my editor tries to use the 'simplest' encoding while trying to detect the correct encoding.

[Joachim Müller]

Exactly. That's what I meant when I said that some editors are acting up. Put a special char into english.php where the charset maps of latin/ANSI and UTF-8 don't overlap (i.e. an Umlaut like ä,ö,ü), convert the file into utf-8 without BOM, save and re-open and you'll notice that the change will stick, as notepad++ has to catter for the additional character. I'm trying to look into this from my Linux box now, with a genuine editor that will never try to fallback to ANSI needlessly. Bluefish (my favorite editor on Gnome/Linux) says that all files inside the lang folder are actually utf-8 files (even english.php), so I'd say that this is something on the end of notepad++.

For now it's good to know that "to BOM or not to BOM"    can have such a drastic influance on some parts of the layout.

The BOM has caused a lot of headache in the past - take a look at http://coppermine.svn.sourceforge.net/viewvc/coppermine/trunk/cpg1.5.x/docs/en/dev_package.htm#packaging_steps_bom and http://forum.coppermine-gallery.net/index.php?action=search2;search=byte%20order%20mark

[Αndré]

Put a special char into english.php where the charset maps of latin/ANSI and UTF-8 don't overlap (i.e. an Umlaut like ä,ö,ü)

I suggest to use a non braking space (ALT + 0160 on my Windows machine, I don't know if that also works on other OS), as it looks silly if we insert a visible character somewhere in the document

I added that character to the header of all language files of the dst plugin in r7458.