TZ Database on Debian Stable for Casablanca ignores the permanent change to DST and Adds an offset of 1 - timezone

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).

Related

How to configure Jenkins job to run every 45 minutes?

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.

NSDateFormatter localizedStringFromDate dateStyle results

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

Should ActiveSupport::TimeWithZone (and Time.zone)'s methods respect DST changes?

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.

Rails 3.1.1 timezone behaviour

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.

Delphi - equivalent to C# DateTime.IsDaylightSavingTime() method needed

I need somehow to determine whether some TDateTime value is within the Daylight Saving Time range for my timezone or not (in C# the same thing does the DateTime.IsDaylightSavingTime() method).
I know in Delphi there's no similar function, because Delphi TDateTime contains no information about timezone, but I suppose there's some way how to do this using Win32 API.
I've looked at Win32 API GetTimeZoneInformation and GetTimeZoneInformationForYear functions, but I don't quite understand how to use them, so I'd like to ask you for help. Thanks in advance for any tips.
Edit:
Example:
In my timezone (Central European) Daylight Saving Time started this year on
28th March at 2 am and ends on 31st October 2010 at 3 am.
I need a function with header:
function IsDaylightSavingTime(input: TDateTime): boolean;
that will return true if the input date is between 28th March 2010 2:00 and 31st October 2010 3:00 and false if not.
(The example is just for year 2010, but I'd need it to work for all years.)
Once again, I know that information saved in TDateTime alone is not enough, but I think that with some Win32 API function I should be able to get e.g. information about current timezone from Windows settings.
It is not as easy as it sounds, because:
1) The switch-over date between DST and standard time is not the same for all countries
2) The switch-over date between DST and standard time is not the same algorithm for the same country for all years (for example in Central Europe it was previously first Sunday in April, IIRC, now it is last Sunday in March). The USA changed from first Sunday in April to the second Sunday in March from 2007 and on.
So - a simple date is not enough, you'll also need a geographical location.
But, if you can live with the fact, that you limit yourself to the switch-over dates that can be calculated from the CURRENT algorithm for the CURRENT year for the CURRENT locale (country) and that this may be wrong for dates both in the future and in the past, then you can use the information in TIME_ZONE_INFORMATION to calculate the switch-over dates:
USES Windows,SysUtils,DateUtils;
FUNCTION GetDaylightSavingsSwitchOverDates(Year : Cardinal ; VAR Start,Stop : TDateTime) : BOOLEAN;
VAR
TZ : TTimeZoneInformation;
FUNCTION DecodeSwitchOverDate(Year : Cardinal ; CONST Time : TSystemTime) : TDateTime;
VAR
I : Cardinal;
BEGIN
Result:=EncodeDateTime(Year,Time.wMonth,1,Time.wHour,Time.wMinute,Time.wSecond,0);
IF Time.wDay=5 THEN BEGIN
Result:=DateOf(EndOfTheMonth(Result))+TimeOf(Result);
WHILE PRED(DayOfWeek(Result))<>Time.wDayOfWeek DO
Result:=IncDay(Result,-1)
END
ELSE BEGIN
WHILE PRED(DayOfWeek(Result))<>Time.wDayOfWeek DO Result:=IncDay(Result);
FOR I:=1 TO PRED(Time.wDay) DO Result:=IncWeek(Result)
END
END;
BEGIN
IF GetTimeZoneInformation(TZ)=TIME_ZONE_ID_UNKNOWN THEN
Result:=FALSE
ELSE BEGIN
Start:=DecodeSwitchOverDate(Year,TZ.DaylightDate);
Stop:=DecodeSwitchOverDate(Year,TZ.StandardDate);
Result:=TRUE
END
END;
FUNCTION StartOfDST(Year : Cardinal) : TDateTime;
VAR
Stop : TDateTime;
BEGIN
IF NOT GetDaylightSavingsSwitchOverDates(Year,Result,Stop) THEN Result:=0
END;
FUNCTION EndOfDST(Year : Cardinal) : TDateTime;
VAR
Start : TDateTime;
BEGIN
IF NOT GetDaylightSavingsSwitchOverDates(Year,Start,Result) THEN Result:=0
END;
Looping through the years 2000 to 2020 on my PC (Central Europe Time Zone), I get the following dates:
DST in 2000: Sun 26 Mar 2000 02:00:00 through Sun 29 Oct 2000 03:00:00
DST in 2001: Sun 25 Mar 2001 02:00:00 through Sun 28 Oct 2001 03:00:00
DST in 2002: Sun 31 Mar 2002 02:00:00 through Sun 27 Oct 2002 03:00:00
DST in 2003: Sun 30 Mar 2003 02:00:00 through Sun 26 Oct 2003 03:00:00
DST in 2004: Sun 28 Mar 2004 02:00:00 through Sun 31 Oct 2004 03:00:00
DST in 2005: Sun 27 Mar 2005 02:00:00 through Sun 30 Oct 2005 03:00:00
DST in 2006: Sun 26 Mar 2006 02:00:00 through Sun 29 Oct 2006 03:00:00
DST in 2007: Sun 25 Mar 2007 02:00:00 through Sun 28 Oct 2007 03:00:00
DST in 2008: Sun 30 Mar 2008 02:00:00 through Sun 26 Oct 2008 03:00:00
DST in 2009: Sun 29 Mar 2009 02:00:00 through Sun 25 Oct 2009 03:00:00
DST in 2010: Sun 28 Mar 2010 02:00:00 through Sun 31 Oct 2010 03:00:00
DST in 2011: Sun 27 Mar 2011 02:00:00 through Sun 30 Oct 2011 03:00:00
DST in 2012: Sun 25 Mar 2012 02:00:00 through Sun 28 Oct 2012 03:00:00
DST in 2013: Sun 31 Mar 2013 02:00:00 through Sun 27 Oct 2013 03:00:00
DST in 2014: Sun 30 Mar 2014 02:00:00 through Sun 26 Oct 2014 03:00:00
DST in 2015: Sun 29 Mar 2015 02:00:00 through Sun 25 Oct 2015 03:00:00
DST in 2016: Sun 27 Mar 2016 02:00:00 through Sun 30 Oct 2016 03:00:00
DST in 2017: Sun 26 Mar 2017 02:00:00 through Sun 29 Oct 2017 03:00:00
DST in 2018: Sun 25 Mar 2018 02:00:00 through Sun 28 Oct 2018 03:00:00
DST in 2019: Sun 31 Mar 2019 02:00:00 through Sun 27 Oct 2019 03:00:00
DST in 2020: Sun 29 Mar 2020 02:00:00 through Sun 25 Oct 2020 03:00:00
but at least some of these years are incorrect due to the algorithm having changed from my locale in the years listed.
Your function would then be:
FUNCTION IsDaylightSavingTime(Input : TDateTime) : BOOLEAN;
VAR
Start,Stop : TDateTime;
BEGIN
Result:=GetDaylightSavingsSwitchOverDates(YearOf(Input),Start,Stop) AND (Input>=Start) AND (Input<Stop)
END;
Maybe it is overkill for your specific application, but the open source project "Olson Time Zone Database for Delphi" allows to access all time zones supported by the tz database project. The tz database gets regular updates with newest daylight savings changes or fixes.
TZDB can be compiled on Delphi 6, 7,
8, 9, 10, 2007, 2009, 2010 and XE or
FreePascal 2.0 and higher. TZDB is
best used with Delphi XE which
introduces TTimeZone class into RTL.
Ondra C. -
Yes, you're correct. You need to:
Set a Delphi TDateTime variable to the date/time you wish
Convert it to Windows SystemTime
Call GetTimeZoneInformation() to get TTimeZoneInformation
Call GetTimeZoneInformationForYear(), with your TTimeZoneInformation struct, to get DST info for your timezone (I'm not sure where you'd get TTimeZoneInformation for some arbitrary timezone - but you should be able to find it on MSDN).
Do the arithmetic to see whether your System time occurs AFTER TTZI.StandardDate (in which case it's standard time), or AFTER TTZI.DaylightDate (in which case it's DST).
Alternatively ...
Perhaps you could just convert this into a Delphi table:
http://www.twinsun.com/tz/tz-link.htm
For any datetime in, any timezone, just see if the given datetime falls within DST, or outside of it. Voila! No Microsoft APIs - just a simple table lookup or if/else case block!
'Hope that helps .. pSM
As you say yourself, that information is not kept bundled with datetimes in Delphi, so you can't simply port this. Every routine that proceduces a tdatetime would have to add this info, which is not the case in Delphi.
Maybe you should explain more what you are really trying to do, and describe the problem less by analogy
I used .net reflector to view the implementation of this function in .net. It is defined as follows, maybe you can convert the math into Delphi? If you need to dig further into this, I suggest opening Reflector for yourself. I think it will help you!
public static bool IsDaylightSavingTime(DateTime time, DaylightTime daylightTimes)
{
return (CalculateUtcOffset(time, daylightTimes) != TimeSpan.Zero);
}
internal static TimeSpan CalculateUtcOffset(DateTime time, DaylightTime daylightTimes)
{
if (daylightTimes != null)
{
DateTime time4;
DateTime time5;
if (time.Kind == DateTimeKind.Utc)
{
return TimeSpan.Zero;
}
DateTime time2 = daylightTimes.Start + daylightTimes.Delta;
DateTime end = daylightTimes.End;
if (daylightTimes.Delta.Ticks > 0L)
{
time4 = end - daylightTimes.Delta;
time5 = end;
}
else
{
time4 = time2;
time5 = time2 - daylightTimes.Delta;
}
bool flag = false;
if (time2 > end)
{
if ((time >= time2) || (time < end))
{
flag = true;
}
}
else if ((time >= time2) && (time < end))
{
flag = true;
}
if ((flag && (time >= time4)) && (time < time5))
{
flag = time.IsAmbiguousDaylightSavingTime();
}
if (flag)
{
return daylightTimes.Delta;
}
}
return TimeSpan.Zero;
}
You can find an example of this in the JEDI Code Library (Open Source) in the JclDateTime.pas unit, in the LocalDateTimeToDateTime function. The Daylight Savings time info is retrieved and used to convert to and from UTC time.
I know this is not an answer to your question, but you might be interested in the following two functions: SystemTimeToTzSpecificLocalTime() and TzSpecificLocalTimeToSystemTime(). The first one converts universal time to a corresponding time for the time zone specified (where nil means your local time zone). The other one works the other way round, but is included only in Windows XP and above, as Borland Help says. If you are going to do a time-zone dependent time conversion only, they should be OK for you. And it is good to know that they check whether the UTC time given is a DST or Standard time. I didn't read it anywhere, however. I just checked it by myself, so please correct me if I'm wrong.
Please, see the following function. I'm not sure whether I would use it anywhere, for I'm not sure about its correctness, but it might be worth seeing. And please, don't tell me it's a stupid method, for I know that :-).
function IsDaylightSavingTime(lLocalTime: TDateTime): boolean;
var
lUniversalSystemTime: TSystemTime;
lLocalSystemTime: TSystemTime;
lTimeZoneInfo: TTimeZoneInformation;
begin
case GetTimeZoneInformation(lTimeZoneInfo) of
TIME_ZONE_ID_UNKNOWN:
begin
Result := False;
Exit;
end;
TIME_ZONE_ID_STANDARD,
TIME_ZONE_ID_DAYLIGHT: ;
else
//TIME_ZONE_ID_INVALID:
RaiseLastOSError();
end;
DateTimeToSystemTime(lLocalTime, lLocalSystemTime);
if not TzSpecificLocalTimeToSystemTime(nil, lLocalSystemTime, lUniversalSystemTime) then
RaiseLastOSError();
Result := SameTime(SystemTimeToDateTime(lUniversalSystemTime),
IncMinute(lLocalTime, lTimeZoneInfo.DaylightBias + lTimeZoneInfo.Bias));
end;

Resources