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;
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).
I got 1234567890123 milliseconds from DateTime.now().millisecondsSinceEpoch.
How do I get Fri Feb 13 2009 23:31:30 in UTC time from that?
DateTime has a constructor called DateTime.fromMillisecondsSinceEpoch.
DateTime.fromMillisecondsSinceEpoch(1234567890123, isUtc: true).toString();
I need to use .next_week not +1.week. Because the .next_week make the date next week and Monday at the same time. It's so comfortable. And then I subtract some hours. But nothing has been changed. Here's my code.
newDate = DateTime.now
newDate = newDate.next_week - 3.hours
=> Sun, 30 Aug 2015 21:00:00 +0900
newDate = newDate.next_week - 3.hours
=> Sun, 30 Aug 2015 21:00:00 +0900
newDate = newDate.next_week - 3.hours
=> Sun, 30 Aug 2015 21:00:00 +0900
Why they can't be used same time? Please explain to me. Thanks.
This has nothing to do with #next_week and - 3.hours working at the same time. It is a misunderstanding about how #next_week works.
#next_week assumes by default a week is Monday-Sunday. This means when calling just #next_week it will return the next Monday at 00:00:00:00.
Example:
DateTime.now.next_week
#=> Mon, 03 Aug 2015 00:00:00 -0400
Okay so that make sense. Now you are substracting 3.hours making it Sunday again
DateTime.now.next_week - 3.hours
#=> Sun, 02 Aug 2015 21:00:00 -0400
Still makes perfect sense. Now here is where the confusion is. Since you rolled back to Sunday by subtracting 3.hours the #next_week is the following Monday again so
(DateTime.now.next_week - 3.hours).next_week
#=> Mon, 03 Aug 2015 00:00:00 -0400
I hope this helps you understand the situation a bit better.
If you use + 1.week this will take you to the same exact point in time the following week
DateTime.now + 1.week
#=> Fri, 07 Aug 2015 09:01:17 -0400
This does not rely on a weekly calendar but rather the basic math of adding 7 days to the referenced Date object.
In conclusion while #next_week might be comfortable you need to understand what it actually implies and I think I would prefer + 1.week in this case for its flexibility and its lack of assumption.
There are also many other methods for traversing time through ActiveSupport such as #advance, #days_since, weeks_since, etc.
Final note next_week can accept a day parameter as well e.g
DateTime.now.next_week(:tuesday)
#=> Tue, 04 Aug 2015 00:00:00 -0400
DateTime.now.next_week(:thursday)
#=> Thu, 06 Aug 2015 00:00:00 -0400
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.