I get result as follow when I execute a sql which includes now()function in VoltDB
select * from test2;
C1
---------------------------
2019-06-29 07:13:38.050000
But,I get another time when I execute a shell command 'date'
[root#localhost config]# date
Sat Jun 29 03:30:09 EDT 2019
How can I make them same？
VoltDB stores time in the UTC timezone. If you want to change this to EDT or any other timezone, you should be able to do it using a variety of methods and languages.
For example, in java you might use VoltTableRow.getTimestampAsSqlTimestamp(0) to get the value of a timestamp row. You could then use DateFormat to convert this to a particular timezone.
You can read more about the "getTimestampAsSqlTimestamp" method here: https://docs.voltdb.com/javadoc/java-client-api/org/voltdb/VoltTableRow.html
Full Disclosure: I work at VoltDB.
Related
my script is checking for files in several directorys. If there is e.g. an mp3 I get the creation date via
time.ctime(os.path.getctime(audio_file_path))
What I need is an Isorepresentation of the date similar to
datetime.datetime.now().isoformat()
my result at the moment looks like this:
Thu May 28 13:58:45 2020
but what I need is this:
2020-06-03T13:36:48.740664"
Is there an easy way to transform the timestamp?
os.path.getctime returns a timestamp, so you can use:
datetime.datetime.fromtimestamp(os.path.getctime(audio_file_path)).isoformat()
just stumbled upon one funny issue in Node.js & MacOs - basically if you run instance of node with set timezone var in .env file, variable TZ, and you local machine is in different timezone, the Date creation is f**d up in the wort way possible, so that:
Timezone is set correctly
But when you create a new Date, the timezone is not reflected
see this example, (my machine is in CET, timezone Europe/Prague) :
~/
11:13 (CET) $ node
new Date()
2019-02-04T10:30:23.053Z # Europe/Prague
new Date().getTimezoneOffset()
-60 # Europe/Prague
.exit
vs. set timezone in TZ env
✔ ~/
11:30 (CET) $ TZ=America/New_York node
new Date()
2019-02-04T10:31:40.968Z # 10:31! :D
new Date().getTimezoneOffset()
300 # America/New_York!
So it is not possible to create a correct date then, since all JS libs like moment uses in the end Date object.
My take is that you should never ever set TZ var while running Node.js server, do I miss something?
Your examples look correct to me. I suspect that your notion of the way the computer keeps track of, and shows, time is upside-down. Your comments imply that you think TZ is used to derive UTC from the computer's internal clock. That's not how it works.
Internally, your Mac is using UTC time. Your Mac is not "in CET". It is "in UTC with a default TZ setting of CET". TZ controls how a local time is derived from the underlying UTC when a local timestamp or timezone offset is required. If you change TZ then local timestamps will be shown in the new timezone, but the computer's internal timekeeping in UTC is not affected.
Specifically for your example, new Date() gets you a Date object representing the current time. The default string representation of a Date object is the UTC time. In your example you can see that this time, shown as the result of the new Date() call:
2019-02-04T10:30:23.053Z # Europe/Prague
is a UTC time because its timezone is shown as Z, indicating UTC. (One way to remember that meaning is that "Z" is for "Zero offset from UTC". This format is sometimes called "Zulu" time because "Zulu" is the ICAO phonetic alphabet's code word for "Z".) If your comment is claiming that this is a local Europe/Prague timestamp then the comment is incorrect.
The result of the second new Date():
2019-02-04T10:31:40.968Z # 10:31! :D
is also shown in UTC and is about a minute later than the first result. It doesn't matter that TZ for this process is different, because TZ does not affect UTC timestamps.
To see the local time, which is calculated by applying the TZ setting to the UTC time obtained from the computer's clock, use the toLocaleString method on the Date object. If you repeat your test using that method you'll see something like this:
$ env TZ=Europe/Prague node
> now = new Date()
2019-02-04T20:26:40.408Z
> now.toLocaleString()
'Mon Feb 04 2019 21:26:40 GMT+0100 (CET)'
$ env TZ=America/New_York node
> now = new Date()
2019-02-04T20:27:12.438Z
> now.toLocaleString()
'Mon Feb 04 2019 15:27:12 GMT-0500 (EST)'
which looks perfectly reasonable.
BTW, Node, or JavaScript, isn't doing anything unusual here. This is the way it works for everything. For example, the date command:
$ env TZ=Europe/Prague date
Mon Feb 4 21:54:49 CET 2019
$ env TZ=America/New_York date
Mon Feb 4 15:54:51 EST 2019
You can solve your issue with moment-timezone node package. below code may help you to resolve your issue.
const moment = require('moment-timezone')
function convertDate(dateInUTCFormat) {
return new Promise((resolve, reject) => {
var dec = moment(dateInUTCFormat);
var normalDate = dec.tz('Asia/Kolkata').format('YYYY-MM-DD'); // GMT +5:30 (India)
resolve(normalDate);
})
}
Also you need to pass the date format that you get in UTC format for eg 2019-02-04T10:30:23.053Z to convertDate function and pass your timezone as i passed my timezone Asia/Kolkata . May this will help you to find your solution.
how to get local date & time in linux terminal while server configured in UTC or different timezone?
here is what I get now but I'd like to see in local timezone. For eg: PST/PDT.
[jenkins#myServer ~]$ date
Thu Jul 28 18:16:48 UTC 2016
I'm not looking to change system time using hwclock or updating /etc/localtime. Just want to change it for a user.
Also, please let me know - how to persist it for future logins.
Use the TZ environment variable to pass the desired timezone to date:
TZ=<timezone> date
You can find the available timezones in the /usr/share/zoneinfo/ directory and subdirectories. For example, /usr/share/zoneinfo/America/New_York defines TZ=America/New_York.
Example:
$ date
Fri Jul 29 06:31:53 BDT 2016
$ TZ='America/New_York' date
Thu Jul 28 20:31:58 EDT 2016
$ TZ='America/Los_Angeles' date
Thu Jul 28 17:31:54 PDT 2016
For a local time, use "date". For UTC time, use "date -u". Note that, if you use "date" in the server's terminal it returns the server local time.
You can show local time by overriding the TZ environment variable for the process which prints the date. POSIX says a lot about the topic, beginning with
This variable shall represent timezone information. The contents of the environment variable named TZ shall be used by the ctime(), ctime_r(), localtime(), localtime_r() strftime(), mktime(), functions, and by various utilities, to override the default timezone.
Conventional 3-character timezone values were some time ago (more or less) standardized to deprecate the 3-character forms, using the combined standard and daylight savings time form. The preferred form used for PDT is PST8PDT.
There's a page on VMware showing the names and mentioning that they are used on Linux; you may notice that very few of those are 3-character form (aside from the generic UTC+offset).
Further reading:
Valid timeZone Values (VMware):
IANA - Time Zone Database
I've got a strange sybase behavior which I do not understand.
Situation
I have a table (MY_TABLE) with several columns of type smalldatetime. For illustration purposes let's assume the following table and data:
MY_TABLE||ID |TS_INIT |TS_LASTCHANGE |MY_TEXT |
||4711|3/31/2013 12:00:00 AM|3/31/2013 3:00:00 AM|someText|
TS_INIT and TS_LASTCHANGE are of type smalldatetime.
When executing the following statement I get the above result:
SELECT ID, TS_INIT, TS_LASTCHANGE MY_TEXT
FROM MY_TABLE
WHERE ID = 4711
go
My client is running in UTC+1 (Berlin) and has daylight savings time (DST) enabled.
I am not sure in what time zone the server is running and whether or not DST is enabled.
Problem
When I execute this (note that it is 03:00h):
SELECT ID, TS_INIT, TS_LASTCHANGE MY_TEXT
FROM MY_TABLE
WHERE ID = 4711 AND TS_LASTCHANGE = "2013-03-31 03:00:00:000"
go
I get NO results but when I execute this (note that it is 02:00h this time):
SELECT ID, TS_INIT, TS_LASTCHANGE MY_TEXT
FROM MY_TABLE
WHERE ID = 4711 AND TS_LASTCHANGE = "2013-03-31 02:00:00:000"
go
I do again get the above result which is saying TS_LASTCHANGE is
3/31/2013 3:00:00 AM
Note that the result prints 03:00h, even though I queried for 02:00h.
Why Is the first query returning no results even though there should be a match and why is the second query returning a result even though there should be no match?!
Note also that 3/31/2013 3:00:00 AM is the first moment in DST (at least in the year 2013) and 3/31/2013 2:00:00 AM should never ever exist at all because when transitioning from winter to summer time, the clock switches from 01:59:59 to 03:00:00 (as per this site).
Database: Adaptive Server Enterprise V15.0.3
Client: Aqua Data Studio V16.0.5
EDIT:
When querying whit the TS_INIT everything works as one would expect (only a result for 3/31/2013 12:00:00 AM)
Aqua Data Studio is written in Java.
The problem you are having has to do with the fact that Java is aware of timezones and databases don't have a concept of timezone when they store date and times. When the time comes back from the database, the database's JDBC driver puts it in a Java date and just assumes the timezone is irrelevant. The problem happens when you try to display a time which the JVM thinks is invalid, so a valid date is presented, which basically pushes the time by an hour. Daylight savings for 2015 started on March 08 2.00 AM and one of your rows contains a date which is invalid according to JVM.
This has been a known design issue with Java, and they are trying to fix this with JSR-310 for inclusion in Java SE 8. With this, they will have LocalDate, OffsetDate and ZonedDate. You can read more about it here ...
https://today.java.net/pub/a/today/2008/09/18/jsr-310-new-java-date-time-api.html#jsr-310-datetime-concepts
https://jcp.org/en/jsr/detail?id=310
http://docs.google.com/View?id=dfn5297z_8d27fnf
Workaround
The only workaround, is to probably trick the JVM by setting the timezone in the JVM to GMT. If you are running ADS 16 on Windows, and you launch ADS with the shortcut icon on the desktop (which runs datastudio.exe), then you need to modify the datastudio.ini file in your folder. Add a new entry for vmarg.5=-Duser.timezone=gmt
This link explains the location of where to find the data studio.ini
https://www.aquaclusters.com/app/home/project/public/aquadatastudio/wikibook/Documentation14/page/50/Launcher-Memory-Configuration#windows
Once you have made the change, Restart ADS. Then go to Help->About->System: and double check your user.timezone setting and make sure it is GMT. Then give it a try.
With the above change there might be side effects in the application where timezone are involved, For e.g. in the Table Data Editor->Insert Current Date&Time, which would display a GMT time ... so there would be an offset.
From where does the date command in Linux get the timezone information?
I cannot see /etc/localtime file and /usr/share/zoneinfo directory in my system. Still when i execute the date command i get the following output
Thu Dec 9 16:28:18 UTC 2010
Kindly tell me from where does the command get the timezone information?
Thanks,
LinuxPenseur
Don't forget that UTC is how standard Unix systems store the date/time in the real time clock. You have to jump through hoops using funny programs (see the hwclock(8) manpage) if you dual-boot to Windows, which prefers the local time to be stored in the CMOS real time clock.
So the date(1) program is simply showing you the results of "I have no configured time zone":
# date -u
Thu Dec 9 10:40:54 UTC 2010
# TZ=UTC date
Thu Dec 9 10:40:57 UTC 2010
# TZ=PST8PDT date
Thu Dec 9 02:41:02 PST 2010
#
From http://www.wikihow.com/Change-the-Timezone-in-Linux
On mobile phones and other small devices that run Linux, the time zone
is stored differently. It is written in /etc/TZ, in the format that is
described, for instance, in [4] . Edit this file manually or use
echo (for instance, echo GMT0BST > /etc/TZ to set the the timezone of
the United Kingdom).
From http://www.radisys.com/files/support_downloads/03245-02_MPCMM0001_MPCMM0002_CMM_Software_TPS.pdf
The CMM determines the offset to local timezone maintained in file
/etc/cmm/TZ and automatically updates the time.
This should help :
http://www.hypexr.org/linux_date_time_help.php