I have created as Yahoo Calender link and it doesn't seem to be respecting the timezone for the end date:
https://calendar.yahoo.com/?v=60&TITLE=Chapter%20Luncheon%20-%20CO%20-&ST=20151022T170000Z&ET=20151022T190000Z&URL=tma.utdev.com&in_loc=Maggiano%27s%20Little%20Italy%20500%2016th%20St%20Ste%20150%20Pavilions%20Mall%2C%20Denver%2C%20CO%2080202%2C%20United%20States&desc=
This displays 1:00PM to 7:00PM. I am in the EST Timezone which is GMT-4:00, so 17:00:00 (aka 5:00) - 4 hours = 1:00 PM. But for the end time, 19:00:00 (7:00), its not converting and its leaving it at 7:00
For google it does work:
https://www.google.com/calendar/render?action=TEMPLATE&text=Chapter+Luncheon+-+CO+-&dates=20151022T170000Z/20151022T190000Z&sprop=website:tma.utdev.com&location=Maggiano%27s+Little+Italy+500+16th+St+Ste+150+Pavilions+Mall,+Denver,+CO+80202,+United+States&details&website=http://tma.utdev.com/event/chapter-luncheon-co&pli=1&sf=true&output=xml#eventpage_6
This displays the date 1:00PM to 3:00PM
From what I can tell, Yahoo Calendar doesn't support an ET parameter. (If it does, it's undocumented and buggy). I'd therefore recommend using the DUR parameter instead, to specify the duration:
https://calendar.yahoo.com/?v=60&TITLE=Chapter%20Luncheon%20-%20CO%20-&ST=20151022T170000Z&DUR=0200&URL=tma.utdev.com&in_loc=Maggiano%27s%20Little%20Italy%20500%2016th%20St%20Ste%20150%20Pavilions%20Mall%2C%20Denver%2C%20CO%2080202%2C%20United%20States&desc=
See http://chris.photobooks.com/tests/calendar/Notes.html or http://taskboy.com/blog/Creating_events_for_Yahoo_and_Google_calendars.html for more information on the supported parameters.
Related
Im trying to trasform a date to utc but moment return the same value i use.
for example
moment(date, 'YYYY-MM-DD HH:mm:ss').utc().format('YYYY-MM-DD HH:mm:ss')
if i use date = '2022-01-07 11:30:00' moment return 2022-01-07 11:30:00
do i have to set the timezone of the value first? why moment return the wrong value? it should return +3 hours that date.
You'll need to define the timezone in which the date is, then the offset will be as expected:
Example, using Europe/Amsterdam as timezone
const date = '2022-01-07 11:30:00';
const utc = moment(date, 'YYYY-MM-DD HH:mm:ss')
.tz('Europe/Amsterdam')
.utc()
.format('YYYY-MM-DD HH:mm:ss');
console.log(utc);
<script src="https://cdnjs.cloudflare.com/ajax/libs/moment.js/2.29.1/moment.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/moment-timezone/0.5.32/moment-timezone-with-data.min.js"></script>
This will output 2022-01-07 10:30:00 since Amsterdam time is -1 compared to UTC.
Small side node, quoting MomentJS Project Status page
We now generally consider Moment to be a legacy project in maintenance mode. It is not dead, but it is indeed done.
In practice, this means:
We will not be adding new features or capabilities.
We will not be changing Moment's API to be immutable.
We will not be addressing tree shaking or bundle size issues.
We will not be making any major changes (no version 3).
We may choose to not fix bugs or behavioral quirks, especially if they are long-standing known issues.
The data you pass in doesn't have any indication of the timezone it's in, so moment is (I believe) assuming it's in utc already.
In related news, look into using the date-fns library instead of moment. Moment is getting old...
Moment github
Moment.js is a legacy project, now in maintenance mode. In most cases,
you should choose a different library.
This returns the same date since you never indicated any timezone
var time = moment("2013-08-26 16:55:00") //this creates time in my tz
You can set a timezone like this:
var time = moment("2013-08-26 16:55:00").tz("America/Los_Angeles");
So Im using Fullcalendar and on dayClick I'm trying to find events that match the day clicked.
var events = $calendar.fullCalendar('clientEvents');
if(events.length > 0) {
for (var i = 0; i < events.length; i++) {
if (date.format('YYYY-MM-DD') == events[i].start.format('YYYY-MM-DD')) {
...
Now
date.format('YYYY-MM-DD')
returns the day I clicked but when the for loop gets to that days events then
events[i].start.format('YYYY-MM-DD')
returns the next day. This seems to be affected by UTC but this applies to ALL days with events. Not just today. I've tried different formats and still the same. Here's something I noticed though:
n
_ambigTime:false
_ambigZone:true
_d:Thu Feb 09 2017 08:00:00 GMT-0500 (EST)
_f:"YYYY-MM-DD HH:mm:ss"
_fullCalendar:true
_i:"2017-02-08 13:00:00"
_isAMomentObject:true
_isUTC:true
_isValid:true
_locale:f
Notice that _d and _i are different. _i is actually the right date/time. So how can I reference that?
All moment properties starting with _ (like _d and _i) are for internal use and should not be used.
If you want to check if two moment object represent the same day you can use isSame passing the second parameter to limit granularity, instead of comparing formatted strings. In your case:
date.isSame(events[i].start, 'day')
The problem is that some of your objects are created in UTC mode (_isUTC: true), so they will be displayed using UTC time (previous day in some cases) instead of local time.
More info about UTC mode here:
By default, moment parses and displays in local time.
If you want to parse or display a moment in UTC, you can use moment.utc() instead of moment().
This brings us to an interesting feature of Moment.js. UTC mode.
While in UTC mode, all display methods will display in UTC time instead of local time.
I noticed something odd when trying to determine if a given datetimeoffset occurred on the beginning or end of a timezoneadjustment (daylight savings).
And I'm not sure if I'm going about this the wrong way or not.
Take the following code for example:
class Program
{
static void Main(string[] args)
{
// Note: this is done on a swedish computer.
int year = 2015;
DateTimeOffset dateTimeJustBeforeOffsetChanges = new DateTime(year, 10, 25, 1, 59, 59);
DateTimeOffset dateTimeRightWhenOffsetChanges = new DateTime(year, 10, 25, 2, 0, 0); // 2015-10-25 02:00:00. This is how we set our offset. We let the implicit conversion do all the work :)
var daylightSavings = TimeZone.CurrentTimeZone.GetDaylightChanges(year);
Console.WriteLine(dateTimeJustBeforeOffsetChanges); // Prints out 2015-10-25 01:59:59 +02:00
Console.WriteLine(dateTimeRightWhenOffsetChanges); // Prints out 2015-10-25 02:00:00 +01:00 This is the exact time when the datetimeoffset starts using offset +02 instead of +01
Console.WriteLine(daylightSavings.End.ToString()); // Prints out 2015-10-25 03:00:00
Console.ReadLine();
}
}
As you can see from the above code, the offset changes from +1 hour to +2 hours on October 25:th at 2 o'clock in the morning when using the implicit conversion from a datetime to a datetimeoffset. However, when analyzing the current daylightsavings with the GetDaylightChanges method whe are told that the change should occur at 3 o'clock on October 25:th.
In my head the offset should change to +2 at 3 o'clock, not 2 o'clock, or am I wrong?
PS: This code is run on a Swedish machine with Swedish timezonesettings.
Firstly, GetDaylightChanges is accurate - the clocks did go back in Sweden at 3am local time.
Secondly, that doesn't mean that you've shown a bug anywhere in the BCL. The problem is simply that 02:00:00 occurs twice - once before the clocks go back, and once after. In other words, it occurs at 2015-10-25 02:00:00 +02:00 and 2015-10-25 02:00:00 +01:00. How do you expect the implicit conversion to tell which one you meant? Both are valid results, and it happens to be picking the later one, although that behaviour is unfortunately unspecified, at least in both the implicit conversion documentation and the DateTimeOffset constructor documentation.
This sort of thing is why in my Noda Time library, when you map from a LocalDateTime to a ZonedDateTime (by applying a time zone) you have to say what you want to happen if the value is ambiguous or skipped - so in this case, you could choose for it to resolve to either the later or the earlier occurrence of 2015-10-25 02:00:00.
Basically this is something you should think about, and decide how you want your application to behave... then you should specify the behaviour you want, using whatever API you're using. That's easier in some APIs than in others :)
Is it possible to go to the start of an event based on an external link.
Example...
<li>Tuesday 10/8/13 10:00 am</li>
<li>Tuesday 10/8/13 1:00 pm</li>
<li>Tuesday 10/8/13 2:00 pm</li>
Upon clicking one of these links, i'd like to have my FullCalendar implementation scroll to that date/time.
Similar to the way this works, only going to the day/time of an event
$('#button').click(function() {
$('#calendar').fullCalendar('today');
});
You can use FullCalendar's gotoDate method. You'd just need to pass in the date parameters in the correct format.
.fullCalendar( 'gotoDate', year [, month, [ date ]] )
I am using the following BlackBerry Java code for parsing the Date by setting its time zone too.
The Default timezone is +01:00 Europe/Belgrade Yugoslavia(YU)
I am using the following code :
Date formatter11 = new Date(HttpDateParser.parse("2013-08-02T14:00:00+04:00"));
Output comes as :
Fri Aug 02 12:00:00 Europe/Belgrade Yugoslavia(YU) 2013
which is wrong . Please let me know the error why parsing is not been correct.
It comes as one hour extra .
Actually , I was concerned for DayLight event that happens with Blackberry phones ... what is that issue .
Are you sure this is one hour extra?
The time seems to saying it is 14:00, and the time zone is UTC + 4 hours, So UTC time is 10:00, Yugoslavia is 1 hour ahead of that, plus daylight saving means 12:00.
Most likely I have missed something.