I have a unix timestamp which I want to convert to local time using moment-timezone library. I am not sure how to do it. Couldn't find anything. Anyone has any ideas?
I tried this but it isn't giving correct local time.
moment.utc(1465297200000).toDate();
The output I am getting is Tue Jun 07 2016 11:00:00 GMT+0000 (UTC).
Whereas I am expecting it to be Tue Jun 07 2016 16:30:00 GMT+0000 (UTC).
Moreover I want the output to be in the format MM-DD-YYYY HH:mm:ss.
There is no reason to bring in moment timezone if you only need the user's local time. Moment timezone is only used when you need to display a time in a timezone other than UTC or the local time of the user.
If you wish to take a point on the global timeline, and display it as the user's local time, use the moment() constructor function:
moment(1465297200000).format()
"2016-06-07T06:00:00-05:00"
Note that I am in a UTC-5 timezone right now, so the UTC time of the time stamp has been shifted back five hours, from "2016-06-07T11:00:00Z" to "2016-06-07T06:00:00-05:00".
I'm not sure why you would expect this to result in 16:30 GMT. Are you in fact wanting it to display in India Standard Time as 16:30? If the computer you are using is set to India time, this should work with the moment function.
To get the format you are looking for, you just need to specify the format tokens to the format function:
moment(1465297200000).format('MM-DD-YYYY HH:mm:ss')
"06-07-2016 06:00:00"
There is no need to call .toDate when you are using moment unless you are interacting with a third party API that expects a date object.
Related
Let's say my timezone is America/Chicago. When Daylights Savings Time ends on Nov 1st, the clock will tick from 1:59:59 CDT (UTC -05:00) to 1:00:00 CST (UTC -06:00), if I understand DST correctly.
This means that on Nov 1st, there will be be two instances of the time span 1am to 1:59:59am. When I create an event in Google Calendar on Nov 1st from 1:30am to 1:45am, how does it know which span of 15min I'm referring to?
Naturally, it seems like the way to distinguish between the first instance of 1:30am to 1:45am America/Chicago and the second instance of 1:30am to 1:45am America/Chicago is by associating their respective offset (UTC -05:00 and UTC -06:00, respectively).
The issue is that Google Calendar doesn't seem to deal with offsets, only timezones, but in this case there are two different instances of 1:30am to 1:45am America/Chicago since the America/Chicago has two different offsets (UTC -05:00 DST, UTC -06:00 ST).
Am I missing something, or is this an edge case / UI issue?
Thanks!
This will depend on the user's perspective. As you can see in the documentation:
You can change your time zone and create events in certain time zones. No matter where you create an event, everyone will see it in their own time zone. This can help with travel plans or make it easy to create events for people around the world.
Calendar uses UTC Time Zone, so:
When events are created, they're converted into UTC, but you'll always see them in your local time.
This means your event at -5:00 UTC from 1:30am to 1:45 am will show up at that time, and after the Time Change it will not be there anymore, as the time changes at 1:59:59 after the event has ended.
In the case your event went from 1:50am to "2:15am", with the Time Change it would actually start at -5 UTC 1:50 and end at -6 UTC 1:15.
I have WCF service, one service method return array of some objects, single object contain some date values, for example {14-05-2013 08:00:00} Kind: Unspecified.
I can see in debug mode this value before return point in method.
On cleint side I getting JSON object that contain wrong date value for my property:
Date(1368511200000+0200)
it is equal to Tue May 14 2013 09:00:00 GMT+0300 (FLE Daylight Time)
it happens just in case when client (browser) and IIS server in different time zones.
Why I see shifted date values and how fix it ?
Thanks.
The date values stay the same, but the presentation shifts because your timezone changes.
08:00 in Berlin is 07:00 in London.
If you want to transfer the same presentation regardless of the fact that it's no longer the same instant in time once this presentation crosses time zones, you could send it as string instead of date.
You could also change the kind of your DateTime to UTC, but that would have implications on your server side as well.
More information about time zone conversion is available here.
First off, I'm not a coder by profession, just a lowly network engineer :) But I'm a big believer in automation and try to write scripts to handle tasks they're suited for
I'm attempting to get the current UNIX timestamp for 10 minutes ago in PowerShell, for use in a database-check script. I'm using this to get the current Unix-time:
$unixtime=[int][double]::Parse((Get-Date -UFormat %s))-600
But when I run it through a UNIX-time to local time converter (http://www.onlineconversion.com/unix_time.htm), I'm getting the current time in GMT (for example, if I run it right now I get "1340620608", which the converter says is 10:36 AM GMT, when the actual time is 10:36 AM CDT). This obviously causes issues when comparing to Unix timestamps in the database, as they are in local time. While I could write (or find) a function that would calculate the current GMT offset and apply it to my timestamp, I was wondering if there is a better way to go about this.
Try:
$unixtime=[int][double]::Parse($(Get-Date -date (Get-Date).ToUniversalTime()-uformat %s))
The above gets the current GMT time first then converts it to the correct format.
Does this work for you?
(Get-Date).AddMinutes(-10).Subtract((Get-Date 1/1/1970)).TotalSeconds
Unix timestamps are defined as seconds since 1970-01-01 00:00:00 GMT.
If the timestamps in your database are stored as seconds since 1970 local time, perhaps you need to fix your database. But it's likely that your database timestamps are standard UTC-based Unix timestamps.
You should also check your system's time and timezone settings; your computer may be treating GMT as local time (and its clock could be several hours off).
If I post a tweet on 08/04/2011 at 9:30AM CDT, the API returns Thu Aug 04 14:19:12 +0000 2011, which translates to 08/04/2011 at 2:19pm. That value is not PDT, and the server I call the API from is in EDT, but none of those match the returned time. I've tried converting to from UTC to my locale, but that didn't seem to matter.
Are you sure it's not UTC? It's UTC is 6 hours ahead of CST and 5 hours ahead of CDT. So the five hour difference is correct in August.
I'd blame the remaining 11 minutes difference on server time on your side, on Twitter's side, or both...
I've got times saved in a sql database in utc format. I'm displaying those times on a gridview, however they are still UTC format. I'd like to convert them to the client's browsers local time. The problem is that although I can get the timezone offset that is only for the current date/time. That offset could change if some of those dates in the future end up occuring during daylight savings time. I'm relatively new to web programming but it seems like what I need to do is run some Javascript as each entry binds to the gridview that somehow takes the C# datetimeoffset object and converts it to a local time. Or maybe that's not possible?
This can be done on the server side if you have a TimeZoneInfo object. You can use the static ConvertTimeFromUtc() method.
In C#:
DateTime localTime = TimeZoneInfo.ConvertTimeFromUtc(myDbDateTime, myTimeZoneInfo);
If you do not have the timezone on the server side things get tricky since javascript does not provide the client's timezone (unless they are in the US, and even then only on some browsers). In this case, it may be best to force the user to select their current timezone and store it against their account. If this is being displayed to anonymous users, you should probably display in UTC by default and provide an option to refresh it for a selected timezone.
Update
There are several issues which appear when trying to automatically determine a user's timezone.
Timezone is not provided to the server by the user agent.
Javascript does not provide access to the timezone (except in some browsers, sometimes).
The javascript function getTimezoneOffset() may initially sound like a good idea, but since there are multiple timezones with the same offset, this is not a unique value. The difference between many of these non-unique zones is their implementation of daylight saving time.
Example: Indiana does not regard DST. Therefore, for half the year their offset matches eastern time, while the other half their offset is equal to central time.
If, however, your user base is located primarily in the US and uses IE, Chrome, Safari, or Firefox, than you can use the toString() method on a Date object to obtain the timezone. These browsers append the timezone to the date string in different ways. Outside the US, the timezone is not included in all browsers (though some may still show it).
Open http://jsbin.com/onulo3 to observe:
IE8: Sun Feb 14 22:12:22 EST 2010
Chrome: Sun Feb 14 2010 22:12:22 GMT-0500 (Eastern Standard Time)
Safari: Sun Feb 14 2010 22:12:22 GMT-0500 (Eastern Standard Time)
Firefox: Sun Feb 14 2010 22:12:22 GMT-0500 (Eastern Standard Time)
With some parsing, you can now determine the timezone for all your American users. For everyone else you can display the time in UTC (with a notice to that effect).
I found the following on "Indiana Daylight Savings Time":
http://www.timetemperature.com/tzus/indiana_time_zone.shtml
As of now, 1/18/2010, a Microsoft system library call
TimeZoneInfo.ConvertTimeFromUtc seems to reflect this behavior, am checking ..
Here are two ways to convert.
Way #1: If you have the datetime in seconds-since-epoch format, just use something like:
var d=new Date(seconds_since_epoch);
document.write(d.toString());
Way #2: If you have only the year, month, day, hour, minute, and second in UTC time, use:
var d=new Date(yyyy,mo-1,dd,hh,mi,ss); // in JavaScript, January is month 0
document.write(d.toString());