I am using the bootstrap datetime picker.
I have set enabledHours between 8 am to 5 pm and stepping to 30. When i pick the current hour to be 5 pm and increment the minute by one step,the result is a invalid date(5:30 pm). The expected result is not to allow incrementing the time, as it produces invalid date.
Same goes for hours also. E.g. if I pick the time as 4:30 pm and try to increment the hour by one step, it produces 5:30 pm which is not valid according to the enabled hours.
Any workaround for this issue?
I found my answer here: https://stackoverflow.com/a/31950948/495000
Turns out the trick is to use the disabledTimeIntervals option instead of EnabledHours.
Note that disabledTimeIntervals takes an array of arrays - representing a list of disabled ranges.
For example, I needed the following, which disables the times between 12:00 AM to 06:59 AM, and between 6:01 PM and 11:59 PM (technically 12:AM the next day the way it's written...). If you consider the inverse, this means I'm enabling from exactly 7:00 AM to exactly 6:00 PM.
.datetimepicker({
format: 'hh:mm A',
stepping: 15,
disabledTimeIntervals: [
[moment().hour(0).minutes(0), moment().hour(6).minutes(59)],
[moment().hour(18).minutes(1), moment().hour(24).minutes(0)]
]
Related
I came across a weird date behaviour in Swift.
If I try to print any date before 1891, the minutes and seconds will be printed incorrectly with offset by 2 minutes and 16 seconds like this:
Code Sample:
// incorrectly printed date
let year1981 = Calendar.current.date(from: .init(year: 1891, hour: 9))
print(year1981!) // will print 1891-01-01 08:02:16 +0000
// correctly printed date
let year1982 = Calendar.current.date(from: .init(year: 1892, hour: 9))
print(year1982!) // will print 1892-01-01 08:00:00 +0000
Is there any rational reason for this behaviour or it is a bug? Thanks for any reply!
Tested in Xcode Playground 14.1
Based on the comments you are in the "Europe/Prague" timezone.
According to this website information:
When local standard time was about to reach
Thursday, October 1, 1891, 12:00:00 midnight clocks were turned forward 0:02:16 hours to
Thursday, October 1, 1891, 12:02:16 am local standard time instead.
This change would explain the results you are seeing when converting such a date.
So it is not a bug. It's just one of many examples of how complicated Date and Calendar code is due to all of the obscure details of time zones and day light saving time can be.
In a scenario where we know the timezone of the user and the date but the time is input by the user in a textbox (i.e. a calendar where an user selects the date but types the time), after it is properly parsed and we know the hours and minutes, how should we deal wih a non-existent time because of DST clock forward (eg. 02:00 does not exist because of clocks are turned forward 1 hour) in order to pass it -at least an existent hour- to DateTime->new();?
use DateTime;
$dt = DateTime->new(
year => $year_userinput, #2016
month => $month_userinput, #03
day => $day_userinput, #27
hour => $hour_userinput, #02
minute => $minute_userinput, #30
second => 0,
time_zone => $timezone_userinput, #Europe/Berlin
);
Error: Invalid local time for date in time zone: Europe/Berlin
As you go into Daylight Savings, there's no problem. Assuming DLS starts at 2am on a given day in the fictitious time zone, ATZ (a timezone) with an offset of N hrs, then the three seconds commencing one second before 2am are timestamped;
1:59:59 ATZ +N
3:00:00 ADZ +(N+1)
3:00:01 ADZ +(N+1)
...and when coming out of Daylight savings ...
2:00:00 ADZ +(N+1)
2:00:01 ADZ +(N+1)
...
... about an hour later
...
2:59:59 ADZ +(N+1)
2:00:00 ATZ +N
2:00:01 ATZ
There appears to have been an earlier "2:00:01" but that included an offset of (N+1) - or was in the timezone ADZ - whereas this one is in ATZ (N). The DateTime module raises the issue like this:
Ambiguous Local Times
Because of Daylight Saving Time, it is possible to specify a local time that is ambiguous. For example, in the US in 2003, the transition from to saving to standard time occurred on October 26, at 02:00:00 local time. The local clock changed from 01:59:59 (saving time) to 01:00:00 (standard time). This means that the hour from 01:00:00 through 01:59:59 actually occurs twice, though the UTC time continues to move forward.
To avoid the issue, you are going to have to always include the timezone or offset when creating time objects. To do that, you need to use the date (you said you had it) to detect that it is end-of-DLS day and, if the user has chosen a time within the critical hour, you're going to have to prompt for "is that 2:30am ADZ or 2:30am ATZ?" or something similar. Likewise, if it's start-of-DLS, your interface has to refuse entries referencing the critical hour.
Earlier in the doco for DateTime, there's the suggestion - for performance reasons - of determining the local timezone once and then using it throughout your app;
our $App::LocalTZ = DateTime::TimeZone->new( name => 'local' );
... # then everywhere else
my $dt = DateTime->new( ..., time_zone => $App::LocalTZ );
... but this is going to leave you vulnerable to the issue again. Since your interface is going to have to know its start-of-DLS day or end-of-DLS day, you can set and use $App::LocalTZ as advised and then override with the specific, prompted-for Timezone if it's end-of-DLS day.
I am handling facebook page feed with webhooks. As part of response I got following JSON. Here I observe time=1451367053 value is not no. of milliseconds from 1 Jan 1970. What is the base Date they use to calculate No. of milliseconds
{entry=[{id=407976012733132, time=1451367053, changes=[{field=feed, value={item=post, verb=add, post_id=407976012733132_420062131524520, is_hidden=false, sender_id=1540815732897198, message=<>, sender_name=Havasay Hs}}]}], object=page}
It seems to be the number of seconds since Jan, 1st 1970 ("epoch time"):
$ perl -e 'print scalar localtime 1451367053'
Tue Dec 29 13:30:53 2015
If you want the number of milliseconds since that day, just multiply by 1000.
I currently have this quartz cron string 0 0/35 11-13 1/1 * ? *. Now what it generally means is Occurs every 1 day(s) every 35 minute(s) between 11 AM and 1 PM. At least from my understanding that is what it means. Though when I look at possible run times I get these.
06/08/2013 11:00:00 AM
06/08/2013 11:35:00 AM
06/08/2013 12:00:00 PM
06/08/2013 12:35:00 PM
06/08/2013 1:00:00 PM
That does not make sense to me. It seems to reset on the hour. Is there anyway for this not to occur? I would like the job to run at 11AM, then 11:35AM and then 12:10PM not 12PM.
Any and all help would be greatly appreciated.
Yes , this is the problem my colleagues encounters every now and then.
As per the documentation for Quartz scheduler ( and yes off-course, as per my understanding of Quartz till now :-p ), cron trigger will be set to fire at "every 35th minute of the hour" and not "every 35th minute in a day".
For your requirement you should use a simple-trigger .
Date firetime=null; //initialize to Your start time of trigger "11.00am"
Date endtime=null; // initialize to Your end time of trigger "1.00pm"
Trigger tr1 = TriggerBuilder
.newTrigger()
.startAt(firetime)
.endAt(endtime)
.withIdentity("First Trigger", "First Group")
.withSchedule(
SimpleScheduleBuilder.simpleSchedule()
.withIntervalInMinutes(35)
).build();
And use another trigger to schedule this trigger daily.:-)
I don't undersatnd why I get 8:00AM instead of 00. This also happens if I set it to other hours.
Ok, I now tryed to present in a label the value of
[dateFormatter stringFromDate:dateTest];
And in a wierd way it presented the time I formatted... But if I check the NSDate object on a breakpoint then it says 08:00:00 and not 00:00:00;
My best guess that you live in the States, which uses GMT -8 time zone at the date specified (maybe PST?). So the date has been parse correctly already, because it said it was GMT.
The dateFormat string is wrong. It should be
"yyyy-MM-dd-HH-mm-ss"
See http://unicode.org/reports/tr35/tr35-4.html#Date_Format_Patterns.
The main problems are
DD is the day of year, not day of month. So 07 will override the month "November" set previously.
hh can only recognize numbers in the range [1, 12], which 0 is out of range.