I am using datediff("h",TimeFormat(stamp), TimeFormat(now)) and checking for a difference gt than 7. If the time is greater than 7 it will update the stamp. It only checks every now and then so its possible for a day to go by with no check. Will the datediff understand that 5AM tuesday is 24 hrs different than 5AM wednesday?
if the variable 'stamp' is a full date/time, then yes. it will correctly calculate the # of hours between value 1 and value 2.
You don't need to format the values passed in either. dateFormat() and timeFormat() are display functions meant to make a date/time value presentable to a human reader. A function (such as dateDiff(), dateAdd(), etc) doesn't need the date value to be formatted in any specific way. It just needs it to be a valid date/time value.
So assuming:
stamp = createDateTime( 2010, 11, 21, 1, 0, 0 ); // creates a date/time of nov 21, 2010 1:00am
dateDiff( 'h', stamp, now ); // this will work. no need for formatting functions.
Related
I'm am new to apex and I'm working on a food ordering application where customers are permitted to change their order details only up to 15 minutes after the order has been placed. How can I implement that ?
Create a validation on date item. Calculate difference between SYSDATE (i.e. "now") and order date. Subtracting two DATE datatype values results in number of days, so multiply it by 24 (to get hours) and by 60 (to get minutes). If that result is more than 15, raise an error.
To provide an alternative to Littlefoot's answer, timestamp arithmetic returns interval literals, if you use SYSTIMESTAMP instead your query could be:
systimestamp - order_date < interval '15' minute
or, even using SYSDATE something like:
order_date > sysdate - interval '15' minute
One note, the 15 minutes seems somewhat arbitrary (a magic number) it relies on the order not starting to be processed within that time limit. It feels more natural to say something like "you can change your order until the kitchen has started cooking it". There's no need for any magic numbers then and considerably less wastage (either of the customers time always waiting 15 minutes or of the kitchen's resources cooking something they may then have to discard).
I'm trying to implement correct DST adjustment handling in my alarm clock app. So I'm reading description for DYNAMIC_TIME_ZONE_INFORMATION that I use to retrieve the current DST adjustment information via the GetTimeZoneInformationForYear API, and it says the following:
DaylightDate:
A SYSTEMTIME structure that contains a date and local
time when the transition from standard time to daylight saving time
occurs on this operating system. If the time zone does not support
daylight saving time or if the caller needs to disable daylight saving
time, the wMonth member in the SYSTEMTIME structure must be zero. If
this date is specified, the StandardDate member in this structure must
also be specified. Otherwise, the system assumes the time zone data is
invalid and no changes will be applied. To select the correct day in
the month, set the wYear member to zero, the wHour and wMinute members
to the transition time, the wDayOfWeek member to the appropriate
weekday, and the wDay member to indicate the occurrence of the day of
the week within the month (1 to 5, where 5 indicates the final
occurrence during the month if that day of the week does not occur 5
times).
If the wYear member is not zero, the transition date is
absolute; it will only occur one time. Otherwise, it is a relative
date that occurs yearly.
I'm also checking the current DST adjustments observed all over the world, and if the relative DST adjustments seem pretty straightforward, I'm not exactly clear how the following adjustments could be conveyed via DYNAMIC_TIME_ZONE_INFORMATION -- with just an absolute month and a day.
For instance:
Egypt
-----
DST Start: May 15
DST End: Last Friday September
or this one:
Iran
----
DST Start: March 21–22
DST End: September 21–22
Does anyone know how to do this?
To understand the time zone structures, it helps to look at the Windows registry under the following key:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\
Here you'll find all of the built-in time zones of the Microsoft time zone database, which is maintained by Microsoft via Windows Updates.
Let's look at one of the example cases you mentioned:
.\Egypt Standard Time\
.\Egypt Standard Time\Dynamic DST\
From this we can see that there are specific DST rules defined for year 2005-2011. Outside this range, we fall back to the TZI value of the root entry.
You'll notice that there the 2014 entry for Egypt is missing. That's because Egypt gave almost no notice about the upcoming change. You can expect that there will soon be a hotfix from Microsoft available with the update.
The binary data in the registry is deserialized to a REG_TZI_FORMAT structure, which looks like this:
typedef struct _REG_TZI_FORMAT
{
LONG Bias;
LONG StandardBias;
LONG DaylightBias;
SYSTEMTIME StandardDate;
SYSTEMTIME DaylightDate;
} REG_TZI_FORMAT;
An issue you should be aware of is that Windows doesn't like time zones that transition right at midnight. The workaround is that instead of saying "00:00 on the last Friday in September", you have to say "23:59:59.999 on the last Thursday in September". However, here you have to be careful because rules like these can sometime lead to erroneous derived dates. To counter that, sometimes each year will have it's own rule. The recurrence-pattern format is still used rather than the fixed-date format, mostly for consistency purposes.
However, there's another problem - This structure can only support two daylight saving time transitions in a year. One at the DaylightDate when DST begins, and one at the StandardDate when DST ends. Since Egypt is enacting DST except for Ramadan, there will be four transitions. This also happened in Egypt in 2010, and also occurs regularly in Morocco. To deal with this design flaw, Microsoft has traditionally released multiple updates, timed to coincide with the changes. (For example, see KB2297272.)
I'll assume Microsoft will push out the multiple-update changes, so for sake of example we'll leave out the Ramadan period. This rule starts DST on the 2nd Wednesday in May at 23:59:59.999 and ends it on the last Thursday in September at 23:59:59.999.
"TZI" = 88ffffff 00000000 c4ffffff 000009000400050017003b003b00e703 000005000300020017003b003b00e703
That corresponds to a REG_TZI_FORMAT structure having these values (as JSON for clarity):
{
"Bias" : -120, // Standard offset is UTC+2
"StandardBias" : 0,
"DaylightBias" : -60, // Subtract an hour for DST
"StandardDate" : {
"wYear" : 0, // Recurrence pattern
"wMonth" : 9, // September
"wDayOfWeek" : 4, // Thursday
"wDay" : 5, // Last occurrence
"wHour" : 23,
"wMinute" : 59,
"wSecond" : 59,
"wMilliseconds" : 999
},
"DaylightDate" : {
"wYear" : 0, // Recurrence pattern
"wMonth" : 5, // May
"wDayOfWeek" : 3, // Wednesday
"wDay" : 2, // Second occurrence
"wHour" : 23,
"wMinute" : 59,
"wSecond" : 59,
"wMilliseconds" : 999
}
}
I think this answer is long enough, so I'll leave it to you to extrapolate the rules for Iran if you like. Though, I'll point out that the Windows data for Iran has been incorrect since 2009 and has yet to receive an update. :-/
As a side note, if you want to specify a fixed date rule, you can provide a non-zero "real" year value. Then the day field represents the actual day - rather than the occurrence. However, this is typically avoided because it only makes sense for the Dynamic DST rules that apply to individual years. It doesn't makes sense to use a fixed-date in the generic TZI entry in the root node.
UPDATE
Microsoft has released an update for Egypt for 2014 in KB2967990.
Iran is an odd one in that the DST transition dates don't conform to the normal rules which the Microsoft registry expects. Eg: 2nd Sunday in March. So I agree that you need to use absolute dates but achieved using the registry format. The DST transition date's weekdays vary nearly every year.
Iran DST transition dates are based on the persian calendar
https://mm.icann.org/pipermail/tz/2003-March/012053.html
So the dynamic registry method would be the answer with a lot of changes every single year!
I have a lot of dates with time in this format:
day.mon.year - hour:min:sec
And I need to convert this dates with time into Unix timestamp.
I used tm structure, but I can't fill those fields:
tm_wday
tm_yday
And I don't must I fill those field, because I don't know do this field have any effect to the value of Unix timestamp.
Help me to choose rigth way to calculate Unix timestamp.
P.S. Dates with time aren't current, they can be date of the 20-th century or future dates (to 2038 year).
P.P.S. I use OS Windows.
POSIX has a formula for exactly what you want:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15
tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
(tm_year-70)*31536000 + ((tm_year-69)/4)*86400 -
((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400
This works whenever you have a broken-down time in GMT, even if the underlying system's mktime, etc. functions do not use the same format time_t as "Unix timestamps".
If your original time is in local time, you can use mktime and gmtime to convert it to GMT using the system's notion of timezone rules. If you want to apply your own timezone offset rules, just do that manually before using the above formula.
If you are on unix, mktime() will get the second part of the timestamp. It ignores the tm_wday and tm_yday fields.
I'm fighting a few days with COleDateTime in MFC.
I have CTime with correct values. Correct years, days, months, hours, minutes and seconds.
I tried a few ways to convert CTime to COleDateTime:
-1.I put CTime data to constructor of COleDateTime
COleDateTime(int nYear,int nMonth,int nDay, int nHour, int nMin,int nSec );
-2. I formatted CTime to time.Format("%m/%d/%y %H:%M:%S");
and passed to ParseDateTime of COleDateTime.
-3. Also I tried to use SetDateTime of COleDateTime
After that I'm getting incorrect values of minutes 1-2 min. more or less.
I have never seen it before and I couldn't find nothing in internet.Everybody says abot loss precision but this a second, not a minute.
Please advice something for me!
Thank you
I think the problem is that COleDateTime internally uses a float for storage, and the value represents the number of days since 30 December 1899.
As the number of days gets larger, the precision of the smaller fields (like minutes) decreases. For example, a float can accurately store the values 1000000 and 0.0000001, but it CAN'T store 1000000.0000001. It doesn't have enough bits of precision.
This limitation is hinted at in the MSDN documentation:
This type is also used to represent date-only or time-only values. By convention, the date 0 (30 December 1899) is used for time-only values. Similarly, the time 0:00 (midnight) is used for date-only values.
So basically, if you want a precise time, set the date to 30 December 1899.
It seems like Microsoft could have just designed this class to store the "days" portion as an integer, but hey, that would be too EASY.
I have a wxString which has a date as its value. The date format is stored depending on the regional setting or locale settings.
For eg. wxString dateStr = "9/10/2013" [dd/mm/yyyy format for Italy as regional locale setting].
When I parse the date string using wxDateTime::ParseDate(dateStr) and try to convert it in time_t using wxDateTime::GetTicks() function. But it swaps the value of day and month when the day is less than or equal to 12 for example 3/10/2013 or 12/11/2013. I am getting month as 3 and 12, and day as 10 and 11 respectively. But it works fine if the date is greater than 12 i.e 14/10/2013 or 28/10/2013.
I want to convert the above date string into time_t depending upon the locale setting. I am using windows as well as linux for development env.
Please help me out from this problem with an example or code snippet.
I suggest you use wxDateTime::ParseDateFormat instead, then you can specify the exact format of the date-string.
The reason you have problem with ParseDate is that it first tries to parse the date-string in American format (where the format is mm/dd/yyyy), and if it fails it tries other formats.