I am working now on a function ot calculate the flight time. I have a very strange problem, because it is a new domain for me.
Here is one example:
Outward:
25.02.2011 11:45 Cologne - Las Vegas 26.02.2011 21:18
Return:
18.03.2011 09:49 Las Vegas - Cologne 19.03.2011 11:05
For this flight Kayak is showing
Outward: 18:33 hours
Return: 17:16 hours
Cologne is GMT +01:00
Las Vegas is America/Los_Angeles timezone -> -08:00
But in the example the flight durariion for the outward flight is calculated with -8 hours offset for Las Vegas and for the return flight with -7 hours offset for Las Vegas. Why?
I have see the timezones here: http://download.geonames.org/export/dump/timeZones.txt
Has anyone any idea?
Thanks
Nik
It's because Daylight Savings Time doesn't start on the same date everywhere.
Las Vegas: DST starts on Sunday, 13 March 2011
Cologne: DST starts on Sunday, 27 March 2011
So since your return flight is on the 18th of March, Las Vegas will be in DST, but Cologne won't be.
Ok, I solve the problem. Thanks for the advice to convert both dates to UTC/GMT first.
Here is the trick:
$reset_timezone = date_default_timezone_get();
// convert the first time
date_default_timezone_set($timezone_identifier1);
$time1 = $date_from.' '.$time_from;
$gmtime1 = gmdate('Y-m-d H:i', strtotime($time1));
// convert the second time
date_default_timezone_set($timezone_identifier2);
$time2 = $date_to.' '.$time_to;
$gmtime2 = gmdate('Y-m-d H:i', strtotime($time2));
// reset the timezone again
date_default_timezone_set($reset_timezone);
--> here calculate the difference < --
Hope it helps anyone else!
Cheers
Nik
Related
I am on a Debian Stable 9 (stretch), the newly updated TZ database for Africa/Casablanca Table currently states isdst=0 and an offset from UTC of +01.
From the DST in Morocco Wiki page
https://en.wikipedia.org/wiki/Daylight_saving_time_in_Morocco
It is clear that a permanent offset of UTC +1:00 was added from October 2018 and daylight savings is now permanently observed.
But during Ramadan the offset has been traditionally reset to UTC 00:00. But the TZ database denotes that they add an offset of +01 and isdst is set to 1.
This issue is only applicable to Africa/Casablanca.
It seems to be an issue with Debian Stable. Any advice on fixing this issue is appreciated
zdump -v /usr/share/zoneinfo/Africa/Casablanca | grep 2019
/usr/share/zoneinfo/Africa/Casablanca Sun May 5 01:59:59 2019 UT = Sun May 5 02:59:59 2019 +01 isdst=0 gmtoff=3600
/usr/share/zoneinfo/Africa/Casablanca Sun May 5 02:00:00 2019 UT = Sun May 5 02:00:00 2019 +00 isdst=1 gmtoff=0
/usr/share/zoneinfo/Africa/Casablanca Sun Jun 9 01:59:59 2019 UT = Sun Jun 9 01:59:59 2019 +00 isdst=1 gmtoff=0
/usr/share/zoneinfo/Africa/Casablanca Sun Jun 9 02:00:00 2019 UT = Sun Jun 9 03:00:00 2019 +01 isdst=0 gmtoff=3600
From the tzdb 2018h release notes (emphasis mine):
Changes to future timestamps
Guess that Morocco will continue to fall back just before and spring
forward just after Ramadan, the practice since 2012. (Thanks to
Maamar Abdelkader.) This means Morocco will observe negative DST
during Ramadan in main and vanguard formats, and in rearguard format
it stays in the +00 timezone and observes ordinary DST in all months
other than Ramadan. As before, extend this guesswork to the year
2037. As a consequence, Morocco is scheduled to observe three DST transitions in some Gregorian years (e.g., 2033) due to the mismatch
between the Gregorian and Islamic calendars.
It was later confirmed that Morocco did indeed adjust its clocks for Ramadan as predicted. You can read the tz discussion thread, or the article about it on timeanddate.com.
Even the Wikipedia article you cited mentions this:
... An exception was made during the month of Ramadan during which clocks reverted to UTC+00:00 (standard time).
https://play.golang.org/p/82QgBdoI2G
package main
import "fmt"
import "time"
func main() {
fmt.Println(time.Now().Format("01-JAN-2006 15:04:00"))
}
The output should be like if date time today is 2016-03-03 08:00:00 +0000UTC
Output: 03-MAR-2016 08:00:00
Time should be in 24hr format.
Your layout is incorrect, it should show how the reference time is represented in the format you want, where the reference time is Mon Jan 2 15:04:05 -0700 MST 2006.
Your layout should be:
"02-Jan-2006 15:04:05"
Note the 05 for the seconds part. And since you specified the hours as 15, that is 24-hour format. 3 or 03 is for the 12-hour format.
fmt.Println(time.Now().Format("02-Jan-2006 15:04:05"))
For me it prints:
03-Mar-2016 13:03:10
Also note Jan for months, JAN is not recognized. If you want uppercased month, you may use strings.ToUpper():
fmt.Println(strings.ToUpper(time.Now().Format("02-Mar-2006 15:04:05")))
Output:
03-MAR-2016 13:03:10
Also note that on the Go Playground the time is always set to a constant when your application is started (which is 2009-11-10 23:00:00 +0000 UTC).
fmt.Println(time.Now().Format("02-Jan-2006 15:04:05"))
See Time package constants
The reference time used in the layouts is the specific time:
Mon Jan 2 15:04:05 MST 2006
which is Unix time 1136239445. Since MST is GMT-0700, the reference time can be thought of as
01/02 03:04:05PM '06 -0700
I'm creating this question so I can have a one-shot reference to all the date and time styles for each of the NSDateFormatterStyle enum values NSDateFormatterShortStyle, NSDateFormatterMediumStyle, NSDateFormatterLongStyle, NSDateFormatterFullStyle.
I often find myself in a position where I'd like to know if these default styles are sufficient for my clients, and it's hard to find all the styles in one place.
All the output below is in order 1 = NSDateFormatterShortStyle, 2 = NSDateFormatterMediumStyle, 3 = NSDateFormatterLongStyle, 4 = NSDateFormatterFullStyle. Please feel free to comment if you'd prefer a different organization of output.
English
2015-03-27, 9:42 AM
Mar 27, 2015, 9:42:45 AM
March 27, 2015 at 9:42:45 AM EDT
Friday, March 27, 2015 at 9:42:45 AM Eastern Daylight Time
Note that the Date Formatter separates Date & Time by "," in Short and Medium styles, and by "at" in long and full styles. Interesting!
French
2015-03-27 09:54
2015-03-27 09:54:07
27 mars 2015 09:54:07 HAE
vendredi 27 mars 2015 09 h 54 min 07 s heure avancée de l’Est
No commas at all here. French dates seem to be 24h.
German
27.03.15 09:58
27.03.2015 09:58:07
27. März 2015 09:58:07 GMT-4
Freitag, 27. März 2015 09:58:07 Nordamerikanische Ostküsten-Sommerzeit
Spanish
27/3/15 10:00
27/3/2015 10:00:05
27 de marzo de 2015, 10:00:05 GMT-4
viernes, 27 de marzo de 2015, 10:00:05 (Hora de verano oriental)
Simplified Chinese
15/3/27 上午10:01
2015年3月27日 上午10:01:40
2015年3月27日 GMT-4上午10:01:40
2015年3月27日 星期五 北美东部夏令时间上午10:01:40
I was playing time arithmetic in rails console. I have subtracted two different times and got back a long number, please see below my code.
a = User.find(1).updated_at # returns Mon, 03 Mar 2014 11:07:43 UTC +00:00
b = User.find(1).created_at # returns Mon, 03 Mar 2014 08:36:50 UTC +00:00
a - b # returns 9053.699814796448
My question is. What is this number 9053.699814796448? Is it time? What is it's unit? and how is that calculated? Is it possible to change the default unit of the outcome?
Thanks
a - b gives you the time in seconds. Check out the Time#- .
I have a problem related to timezone behaviour of a Rails 3.1.1 application. Here is, what I did on my console:
(rdb:1) Time.zone = "Amsterdam"
"Amsterdam"
(rdb:1) Time.zone.parse("Sun, 06 Nov 2011 13:05:18 +0000")
Sun, 06 Nov 2011 14:05:18 CET +01:00
(rdb:1) Time.zone = "Atlantic Time (Canada)"
"Atlantic Time (Canada)"
(rdb:1) Time.zone.parse("Sun, 06 Nov 2011 13:05:18 +0000")
Sun, 06 Nov 2011 09:05:18 AST -04:00
My object's timestamp is UTC. In my timezone Amsterdam it was 14:05 when I created it. In New York City the timezone is "Atlantic Time (Canada)". Parsing the timestamp in that zone results in 09:05. But thats wrong, it should be 08:05.
Besides that the time difference between both zones seems to be -4 -1 = -5 but is in fact -6 hours.
That behaviour completely destroy's my apps behaviour. What am I doing wrong here?
Regards
Felix.
You are not doing anything wrong. The DST changed today, Nov 6, at 2 AM. So the time is 9:05, and not 8:05. Also, New York is in Eastern time, not Atlantic time.