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
Related
I am trying to configure a Jenkins job to run every 45 minutes:
*/45 * * * *
But the latest intervals of the running job don't look fine to me ever since I changed it:
Mar 27, 2020 11:45 AM
Mar 27, 2020 11:00 AM
Mar 27, 2020 10:45 AM
Mar 27, 2020 10:00 AM
Mar 27, 2020 9:45 AM
Mar 27, 2020 8:36 AM
Mar 27, 2020 7:36 AM
Mar 27, 2020 6:36 AM
As you can see, before changing the interval, the job ran once every hour.
I actually expected the output to be like this:
Mar 27, 2020 12:45 AM
Mar 27, 2020 12:00 AM
Mar 27, 2020 11:15 AM
Mar 27, 2020 10:30 AM
Mar 27, 2020 9:45 AM
What's wrong with my configuration?
You are running your job every 45 minutes within an hour. Each hour is handled separately and counter starts over.
Simplest fix is to change interval to hour or 30 minutes (in general to something that divides an hour without reminder) - this way you'll have even intervals without extra effort. Con is obvious - frequency is not exactly what you wanted.
Other way is to set intervals to smaller value (like 15 minutes) and check time in job (and exit job if time didn't pass yet). Con is that you need extra logic in job and that you have "empty" builds in history.
Last option is to set every trigger manually - 32 triggers a day for "every 45 minutes". It can be quite compact for some intervals (like 45 minutes), but in case you wanted to change it to "every 41 minutes" it becomes a mess.
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).
okay, lets say we have three date ranges.
1. date1=01-20-2015..02-15-2015
2. date2 = 01-01-2015..01-31-2015
3. date3 = 02-01-2015..02-28-2015
I need a way to calculate how many days between date1 and date2 are overlapped (10 days in this case).
and how many days between date1 and date3 are overlapped (15 days in this case)?
Is there a easy way to calculate this?
If you have:
r1= (Date.new(2015, 01, 20))..(Date.new(2015, 2, 15))
r2= (Date.new(2015, 01, 1))..(Date.new(2015, 1, 31))
You can check the intersection this way:
r1.to_a & r2.to_a
=> [Tue, 20 Jan 2015,
Wed, 21 Jan 2015,
Thu, 22 Jan 2015,
Fri, 23 Jan 2015,
Sat, 24 Jan 2015,
Sun, 25 Jan 2015,
Mon, 26 Jan 2015,
Tue, 27 Jan 2015,
Wed, 28 Jan 2015,
Thu, 29 Jan 2015,
Fri, 30 Jan 2015,
Sat, 31 Jan 2015]
The cost is to convert ranges to arrays though
You can notice (r1.to_a & r2.to_a).count #=> 12, not 10 but well depends whether or not you include boundaries.
Look at this code:
[4, 5, 6, 7].each do |x|
start_at = Time.zone.parse("2014.10.2#{x} 08:00")
puts "#{start_at.inspect} / #{start_at.seconds_since_midnight/60}"
end
Output:
Fri, 24 Oct 2014 08:00:00 CEST +02:00 / 480.0
Sat, 25 Oct 2014 08:00:00 CEST +02:00 / 480.0
Sun, 26 Oct 2014 08:00:00 CET +01:00 / 480.0
Mon, 27 Oct 2014 08:00:00 CET +01:00 / 480.0
We are in Germany, and on October 26 the DST is reset so 08:00 is not actually 8*60 minutes since midnight but 9*60.
IMHO, this should be respected by the seconds_since_midnight method. Am I missing something or is this actually a Ruby bug?
Using Ruby 1.9.3, Rails 3.0.20 on Mac OS X 10.9.5 (MacPorts).
(Yes, Rails 3.0.20 is old. Legacy project. If it's fixed in Rails 4, all the better.)
According to the Rails docs, it's implemented as such:
# File activesupport/lib/active_support/core_ext/date_time/calculations.rb, line 14
def seconds_since_midnight
sec + (min * 60) + (hour * 3600)
end
Thus, this function is not time zone aware. It simply looks at the local time value. It does not consider that the offset of midnight might not be the same as the offset of the value you provided. Nor does it consider that midnight might not exist in the local time zone (such as with Brazil's spring-forward transition).
Is this a bug? Perhaps. But one might also say the method is just poorly named. Either way, it's an issue with Rails, not with Ruby.
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.