I have written a new parser function for time and date formatting, called #time. It is an interface to Language::sprintfDate, a function which I wrote a few weeks ago to support internationalisation. Documentation is at:
http://meta.wikimedia.org/wiki/ParserFunctions#.23time
It allows things like {{#time:F|+2 hours}} to get the month name in CEST.
-- Tim Starling
On 8/27/06, Tim Starling t.starling@physics.unimelb.edu.au wrote:
I have written a new parser function for time and date formatting, called #time. It is an interface to Language::sprintfDate, a function which I wrote a few weeks ago to support internationalisation. Documentation is at:
http://meta.wikimedia.org/wiki/ParserFunctions#.23time
It allows things like {{#time:F|+2 hours}} to get the month name in CEST.
Excellent! This will make a ton of ridiculously complicated templates obsolete. Could you add the rest of the letter codes? I'm sure people would find U useful if they needed to do date arithmetic, for instance. It shouldn't reduce performance, since the case statements would be at the end and therefore just ignored unless they match, right?
Simetrical wrote:
On 8/27/06, Tim Starling t.starling@physics.unimelb.edu.au wrote:
I have written a new parser function for time and date formatting, called #time. It is an interface to Language::sprintfDate, a function which I wrote a few weeks ago to support internationalisation. Documentation is at:
http://meta.wikimedia.org/wiki/ParserFunctions#.23time
It allows things like {{#time:F|+2 hours}} to get the month name in CEST.
Excellent! This will make a ton of ridiculously complicated templates obsolete. Could you add the rest of the letter codes? I'm sure people would find U useful if they needed to do date arithmetic, for instance. It shouldn't reduce performance, since the case statements would be at the end and therefore just ignored unless they match, right?
I assume (and hope) PHP case statements are implemented with a hashtable, otherwise they would be very inefficient. I have no problem with adding more format characters in principle, it's just a matter of development time.
This time formatter would probably be one of the slowest parts of the parser per-character, which is why I used memoization and a 1000-byte limit on actual (post-memoize) processing per page, since the initial commit. Hopefully the limit won't affect any legitimate users.
-- Tim Starling
On 8/27/06, Platonides Platonides@gmail.com wrote:
Please also add support for the Summer time change, as i didn't find on the doc :P
What sort of support do you want?
Depending on the month of the year, you may be +1 or +2 from the UTC... (it's the difference between CET & CEST)
Just professional curiosity, how would you define when daylight saving time is enabled/disabled? There're different rules for different countries. And some countries don't have it at all :-(
Domas Mituzas wrote:
Depending on the month of the year, you may be +1 or +2 from the UTC... (it's the difference between CET & CEST)
Just professional curiosity, how would you define when daylight saving time is enabled/disabled? There're different rules for different countries. And some countries don't have it at all :-(
Presumably the same way the computer does it; provide a location such as 'Europe/Berlin' or 'America/Los_Angeles' and let the C library look in its big list of locales.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
Domas Mituzas wrote:
Just professional curiosity, how would you define when daylight saving time is enabled/disabled? There're different rules for different countries. And some countries don't have it at all :-(
Presumably the same way the computer does it; provide a location such as 'Europe/Berlin' or 'America/Los_Angeles' and let the C library look in its big list of locales.
Oh, goody, more things for you devs to keep in sync when a country arbitrarilty decides to massively redefine the period over which Summer Time is set. Not that any country would ever do that. :-)
Yours sincerely, -- James D. Forrester Wikimedia : [[W:en:User:Jdforrester|James F.]] E-Mail : james@jdforrester.org IM (MSN) : jamesdforrester@hotmail.com
James D. Forrester wrote:
Brion Vibber wrote:
Presumably the same way the computer does it; provide a location such as 'Europe/Berlin' or 'America/Los_Angeles' and let the C library look in its big list of locales.
Oh, goody, more things for you devs to keep in sync when a country arbitrarilty decides to massively redefine the period over which Summer Time is set. Not that any country would ever do that. :-)
Ah see, but we can ignore it and leave that to the distro vendors. ;)
-- brion vibber (brion @ pobox.com)
Brion wrote:
James D. Forrester wrote:
Oh, goody, more things for you devs to keep in sync when a country arbitrarilty decides to massively redefine the period over which Summer Time is set.
Ah see, but we can ignore it and leave that to the distro vendors. ;)
This is worth highlighting. Anyone writing code which has to handle summer time changes (or indeed anything timezone-related), and who implements this by re-coding the algorithms and having a private database of the various locale-specific rules, is making a Big Mistake. This is a hard problem that cries out to be solved in one central place, and in fact it has been for years now.
On 28/08/06, Steve Summit scs@eskimo.com wrote:
This is worth highlighting. Anyone writing code which has to handle summer time changes (or indeed anything timezone-related), and who implements this by re-coding the algorithms and having a private database of the various locale-specific rules, is making a Big Mistake. This is a hard problem that cries out to be solved in one central place, and in fact it has been for years now.
GMT for the win!
Rob Church
Well, i was thinking in something even simpler. On the #time you give it a parameter saying use daylight saving time. That would solve the countries don't supporting it. It'd move an hour forward (though i don't like the 'usually' word on the article). The hour of when it changes seems quite regular. The exact timezone change day is a bit more tricy. Underlaying arquitecture should be able to handle the whole process.
Depending on the month of the year, you may be +1 or +2 from the UTC... (it's the difference between CET & CEST)
Just professional curiosity, how would you define when daylight saving time is enabled/disabled? There're different rules for different countries. And some countries don't have it at all :-(
Presumably the same way the computer does it; provide a location such as 'Europe/Berlin' or 'America/Los_Angeles' and let the C library look in its big list of locales.
I did some brute-force testing of PHP's strtotime() implementation [for every known timezone, on every day from 1 Jan 1970 to 31 Dec 2037, performed jumps to every day of the week, i.e. approx 250*(2037-1970)*365*7 = 43 million tests], and filed some corner-case bugs (e.g. you ask for strtotime for a "Tuesday", and it gives you a day that's a Friday), so I can maybe fill-in some of the rough details here.
As I understand it, up until PHP 5.1, PHP used to use the O/S libraries for timezone details and determining daylight savings. However the time/date handling was completely rewritten in PHP 5.1 by Derick Rethans, so that PHP now supplies its own timezone data (in this large header file: http://chora.php.net/viewvc.cgi/php-src/ext/date/lib/timezonedb.h?view=marku... ). One of the benefits of this is that for OSes with dodgy daylight savings/timezone handling (Windows in particular), which brute-force testing showed to be completely broken, you can largely avoid the O/S, and do-it-yourself, and get the same behaviour on different platforms (which is obviously a good thing when you're a cross-platform language). The new date/time implementation seems much more robust, and it also includes a mechanism whereby updated files can be dropped into place in the event of future timezone changes (without recompiling PHP).
And here's a weird factoid for the day: Did you know that there have been 3 occasions in history where a day was *not* followed by the next day in the week (e.g. a Saturday was followed not by a Sunday, but by a Monday)? All three were caused by Pacific Island areas (Pacific/Kwajalein, Pacific/Enderbury, and Pacific/Kiritimati) deciding that they wanted to move from one side of the international date line to the other, and when they moved, they simply lost a whole day. :-)
All the best, Nick.
wikitech-l@lists.wikimedia.org