Seems to be a basic question but I can't find an answer other than "PHP handles it for you" and that isn't what I'm after.
Currently, if I echo date_default_timezone_get(); I get Europe/London
GREAT.
How can I tell if it is BST or GMT.
I need to display Europe/London BST or Europe/London GMT based on what it currently is at.
How can I reliably do this?
Simple enough - get the current time in UTC and compare it to the current time in Europe/London. If they differ, BST is in effect. If they're identical, it isn't.
Alternatively, use date()'s O, P, or Z parameters in essentially the same way - they should be +0000, +00:00, or 0 respectively if GMT is in effect. (I might work, too - I'm not sure if BST is technically considered "Daylight Savings Time"...)
Related
Currently I'm converting all my PHP unix timestamps to work beyond 2k38 issue.
I noticed that setcookie() expire date parameter uses the unix timestamp. Is there a way to set expire date with alternative method, maybe using the DateTime class somehow?
From the PHP document about expire date:
Note: You may notice the expire parameter takes on a Unix timestamp,
as opposed to the date format Wdy, DD-Mon-YYYY HH:MM:SS GMT, this is
because PHP does this conversion internally.
You cannot change the function signature. Well, not at least without fiddling with strange PHP extensions. But since the cookie spec does not use Unix timestamps at all you can simply write your own function and call header() manually:
Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2099 10:18:14 GMT
Set-Cookie: lang=en-US; Max-Age=8640000
... and hope that browsers are able to process the date:
If the expiry-time is later than the last date the user agent can
represent, the user agent MAY replace the expiry-time with the last
representable date.
Or you can simply use seecookie() anyway. As far as I know, it'll only be an issue in some 32-bit versions of PHP.
I need to send a querystring parameter to our API server which is taking times in GMT format.
I am a bit confused about what values I need to send during the summertime, since the dates are in GMT format.
Let's assume we are in London (UK), it's 3PM, and it's the 15th of May
2016.
Is the correct date value:
?date=2016-05-15T15:00:00Z
or
?date=2016-05-15T15:00:00+01:00
or
?date=2016-05-15T16:00:00Z (assuming I always want to use the Z "Zulu Time")
Since London is in BST on that date, then 2016-05-15T15:00:00+01:00 would be the most fully qualified correct form.
If you were to normalize that to UTC, then it would become 2016-05-15T14:00:00Z. Z is equivalent to +00:00, so you have to adjust the hour by the inverse of the original offset.
2016-05-15T15:00:00Z is incorrect, as that is an hour later.
As to which of the two correct forms are more correct for your particular API, there's no way to answer that as you gave no details about how the API is designed, what language it's implemented in, what code is parsing the input, etc. In many cases, either would be accepted. However if the API requires to know local time as well as the universal time, then only the 2016-05-15T15:00:00+01:00 for would convey both.
Also, recognized that there's no such thing as "GMT format". GMT is a time zone, equivalent to UTC+00:00. What you actually have here is a string in ISO8601 extended format, also specified under RFC3339. This is commonly said to be the "ISO format".
I'm creating a mobile version of a website. On the normal version we just use a jquery date picker to select the date. I haven't added anything like this yet on the mobile version because It seemed my Iphone was smart enough to realise it was a date field and give you date scrollers.
But after I've selected the date it's coming up at 7 Aug 2012 which raises a few questions for me... is this standard? or am I going to have to code for different date formats coming from different phones?
Would it be best to use a jquery date picker? (I'm not sure this would be very tidy).
What's the best way to convert a date like this into a format that php and my database can handle. I have done a bit of looking around google but haven't found much as of yet.
Try this
<?php
$today = date('Y-m-d', strtotime('7 Aug 2012'));
echo $today;
?>
gives 2012-08-07
You can change its output by altering Y-m-d in date()
Refer this!
$date = DateTime::createFromFormat('j M Y', '7 Aug 2012'); is the most robust way to do it if you know the format. strtotime guesses which isn't necessarily a good thing, and you won't be informed (i.e. an exception won't be thrown) if the date is in a bad format.
See the manual here: http://www.php.net/manual/en/datetime.createfromformat.php
I don't think the date format is standard. It is very probable that it is affected by the user settings (eg. locale). Eg. if the user defines a Portuguese locale I think the date would be a little bit different.
Using jquery date picker you have the advantage of being able to specify your desired format (applying the dateFormat option). Then you could safely write a PHP script that reads the date in your defined format. You can use PHP's date() function as specified by #Bhuvan Rikka.
Suppose now I've got the datetime to show like this:
2010-05-29 15:32:35
The the corresponding time zone can be get by date_default_timezone_get,
how do I output the result in the same time zone as user's browser so that users don't get confused?
There is no reliable way to read the user's locale timezone settings from PHP or JavaScript.
In JavaScript you can read the offset between UTC and the time in the user's current timezone, but that doesn't give you a timezone name, so you're left either leaving the timezone identifier off (making the times completely ambiguous) or including it is an explicit offset like UTC+01:00, which is ugly, and still doesn't take care of changing timezones over different DST periods.
As bobah says, you can use toLocaleString() on a JavaScript Date to output it in the client's real desktop timezone. However, this way you get no control at all over the date formatting. For example on my machine Chrome outputs the unwieldy:
Sat May 29 2010 15:03:46 GMT+0200 (W. Europe Daylight Time)
Whereas Opera just coughs up:
29/05/2010 15:03:46
Which, as it doesn't state the timezone at all, is uselessly ambiguous. IE is similarly terse, and Safari states no timezone either. Firefox does for me on Linux, but not on Windows. Argh.
So if you need reliability the only way to handle timezones is to let the user manually choose one in their site settings, then convert from UTC to that timezone when you're producing a page for them. You can make a guess in JavaScript as to which the most likely of some common timezones it might be (see this question for strategies), but you can't guarantee you'll be right.
You can pass UTC timestamps to the page and convert them with JavaScript. I used this trick once and was happy with the result. There is a constructor of JavaScript Date taking UTC timestamp. For UTC timestamp generation from PHP one may use gmmktime().
I am using PHP and jQuery to build an interactive timeline which needs to display dates between 1500 and 2020. I usually use PHP's strtotime function when working with dates, but it does not work for dates pre-1900.
The dates will come from a MySQL database, and are formatted as strings such as "January 31, 1654" (this may not be the ideal format, but I can't change how they are stored). I am using PHP to parse the dates, basically converting them into pixel values which determine where they are displayed on the timeline.
What is the easiest way to parse these historical dates?
The DateTime class, here, might help (quoting):
Each component of date (e.g. year) is
internally stored as 64-bit number so
all imaginable dates (including
negative years) are supported.
But note that:
It's only exists in PHP >= 5.2
And several methods only exist in PHP >= 5.3
So: beware of which methods you're using, if you're developping on PHP 5.3 and want your software to be compatible with PHP 5.2
Another solution (especially, if using Zend Framework in your application) would be the Zend_Date component (quoting):
Although PHP 5.2 docs state, "The
valid range of a timestamp is
typically from Fri, 13 Dec 1901
20:45:54 GMT to Tue, 19 Jan 2038
03:14:07 GMT," Zend_Date supports a
nearly unlimited range, with the help
of the BCMath extension
Using the wonderful Carbon Library, dates in the past are not a problem:
$date = Carbon::now();
$date->subCenturies(23);
echo $date->format('Y-m-d');
// -0282-03-15
This works for dates where humans have been around. For everything else, using a date (with day and month, set on the AC/BC scale) does not make a lot of sense.