I have a Linux server (CentOs to be specific) with npm installed. The server's timezone was UTC and I changed it to IRAN (+4:30).
Now my linux timezone is IRAN (say 7:00 PM) while my node Date() returns UTC (4:30 PM).
How can I change the default timezone of Node entirely (and not on a running applications)? I searched a lot and every answer I found was targetting node apps, not the node service in general. I want Node's timezone changed, not the app.
:( by the way, my CentOs does not have any GUI. Answers in text mode are welcome
I found the solution by trying different approaches.
First I changed the Timezone of Centos, and my application on pm2 was still on UTC timezone.
Then I changed the TZ var using cp /usr/share/zoneinfo/Asia/... and still no result.
Then I restarted my CentOs server excpecting the changes to take effect, but no result yet. After server was up, and pm2 reloaded my application, it was still using UTC timezone.
Finally I deleted my application from pm2, and then added it again. That was when my application started using the local timezone.
So keep in mind that no matter what you do to the "Linux TimeZone" or "TZ var", pm2 remembers the timezone of the moment you add your application, and keeps that somewhere and uses that as the timezone of your application.
Related
I have written a blocking user system in node.js. I'm using nodejs, mongodb as data base and mongoose, expressjs and Reactjs.
I have successfully written the blocking logic and unblocking logic. I used mongoose $currentdate feature which fetches the currentdate but uses the current date of the local machine.
I simply said if expiryDate === currentdate, user should be unblocked.
I also tried to use Javascript to get the current date and it uses the local machine date and time.
Why I feel this isn't right is because the user's date and time maybe wrong. I tried this out by setting a wrong date on my local machine and the Javascript date system was setting a wrong date for me as well. This will surely make a mess of the unblocking logic.
If I write my logic using this, it can be dangerous since I do not have control over the user's local machine date and time settings.
Is there really a better way to get this done? I will be deploying the application to be hosted online in Amazon ec2 or haroku. This is part of my learning process actually. Wanted to know how this really work.
How do applications that use billing methods track my days? For instance, if I start a subscription today and the subscription lasts for 7 days, no matter the current state of my local machine date and time, the subscription will surely expire on the 7th day.
How can I achieve this? I would like the expiry logic to be independent of the user's local machine date and time.
Any npm package that can do this or best way to go about this?
If you don't want to depend on the system date, you have to use NTP (Network Time Protocol)
To use NTP in your node script, you can use an NTP module, one of these for example:
https://www.npmjs.com/package/ntp-time
https://www.npmjs.com/package/ntp-time-sync
https://www.npmjs.com/package/ntp-client
Today I found out that a linux's server clock, hosting a PostgreSql cluster in a production environment, is late and I need take it to the current time.
I've used these lines in my local machine:
sudo date --set="2017-01-19 12:09:59.990"
sudo hwclock --systohc
I've listed the time on PostgreSql
select now()
before and after the changes, and everything worked fine.
Is there any impact that I should look for ?
Am I overthinking this ?
I cannot think of any problems that PostgreSQL itself would have with that, and jumping forward in time should not be a problem anyway – it is much like a time with zero activity.
Jumping back in time may not be a problem for PostgreSQL, but it might confuse an application to find future timestamps in the database.
Is there a difference between the timezone setting for the OS (a RedHat Linux build in my case) and the timezone for the actual Apache server on that OS? If so, which of the two am I seeing when I run date on the command line, and how can I change them individually? Thanks.
By default, the system-wide time zone should be the one you're seeing when running the date command. Apache should not, by default, have an additional time zone configured.
Software such as PHP, if you're running it, can have additional time zone settings (for PHP, it can be defined in the php.ini file via the date.timezone option).
I have an IIS 7.0 server configured to rollover logs daily. However it appears that the logs rollover at 10am each day. How/where do I configure this so that they roll over at 1am?
The logs use UTC and roll-over UTC day bounaries, this is by-design.
You can switch to Local Time by checking the "[ ] Use local time for file naming and rollover" box on the Logging screen in IIS Manager.
Besides local vs UTC, you cannot specify a custom timezone or arbitrary point in time for the rollover.
I'm from Russia, and 1,5 days ago (at 2AM, Oct 26) our timezone (ok, offset of our timezone) has changed - from UTC+4 became UTC+3. Please, don't ask why now - it's out ******* goverment :( But it changed.
My home Win 8.1 machine updated automatically.
But only one (!) of my Azure resources is updated. One Cloud Service updated, while one more Cloud Service and 4 websites are not updated - they are still at UTC+4 offset.
I know, all Azure servers are in UTC in settings, but I speak about TimeZoneInfo data on them.
I'm requesting
var tz = TimeZoneInfo.FindSystemTimeZoneById("Russian Standard Time")
and this timezone is still
(UTC+04:00) Moscow, St. Petersburg, Volgograd
while my home machine is in
(UTC+03:00) Moscow, St. Petersburg, Volgograd (RTZ 2)
AFAIK, this depends on system updates on server - new timezone data must arrive prior to any time changes can actually happen. But why servers are not updated?
My one CloudService as working properly now, showing correct timezone info (can't show it), so at least one server is updated correctly, while others are not.
I made small website to test this: http://timezonetestrussia.azurewebsites.net/ (source: https://github.com/justdmitry/AzureTimeZoneTest )
It shows TimeZoneInfo.Local info and from "Russian Standard Time". At this moment, it shows this in Azure:
Id
Russian Standard Time
DisplayName
(UTC+04:00) Moscow, St. Petersburg, Volgograd
StandardName
Russian Standard Time
DaylightName
Russian Daylight Time
BaseUtcOffset
04:00:00
SupportsDaylightSavingTime
True
DateTimeOffset.UtcNow
10/27/2014 2:37:58 PM +00:00
TimeZoneInfo.ConvertTime(DateTimeOffset.UtcNow, tz)
10/27/2014 6:37:58 PM +04:00
While on my local machine it shows:
Id
Russian Standard Time
DisplayName
(UTC+03:00) Moscow, St. Petersburg, Volgograd (RTZ 2)
StandardName
Russia TZ 2 Standard Time
DaylightName
Russia TZ 2 Daylight Time
BaseUtcOffset
03:00:00
SupportsDaylightSavingTime
True
DateTimeOffset.UtcNow
27.10.2014 14:33:50 +00:00
TimeZoneInfo.ConvertTime(DateTimeOffset.UtcNow, tz)
27.10.2014 17:33:50 +03:00
The most likely reason is that different services run on different Guest OS "versions". You likely have automatic Guest OS updates enabled (osVersion="*") which means that Azure is free to update the Guest OS. Different Guest OS versions withing the same family include different sets of updates. Things like rules for timezone adjustments are typically distributed using updates too.
Look at guest OS updates feed http://sxp.microsoft.com/feeds/3.0/msdntn/WindowsAzureOSUpdates - they cannot release a new OS to all users for months already. The process was started multiple times, they updates some of the users and then stopped the process. It's likely that your "proper working" service got the OS updated and the other services have not got the OS updated. You can perhaps verify this using Management API http://msdn.microsoft.com/en-us/library/azure/ee460804.aspx Get Deployment call.
I am researching if Azure can be updated with the new time zones, but I don't believe it is directly possible. Or rather, since you aren't given access to the OS that your Azure Web Site runs on, you wouldn't be able to apply the updates yourself. You will likely have to wait until the next major Azure Guest OS update. I will update this post if I learn otherwise.
If you can rework your program, you might instead consider using Noda Time. It has its own time zone data, which comes from the IANA time zone database. Be sure to use an updated .NZD file, as the Russian changes are covered in IANA 2014f or greater.