can I adjust time settings in the application so that correct times (in terms of my TZ) are saved? Or do I have to adjust the server time?
Time zones are handled in Moqui in a standard way. The point in time in Timestamp objects has no time zone (milliseconds since epoch) so the time zone only comes into play when converting it to another form, such as parsing a String from user or other input or printing a String... or in some cases saving to and loading from a database.
Some databases use a no timezone internal representation, for others ALL Timestamp, Date, Time objects are saved and loaded using the database time zone. The database time zone is set using the entity-facade.#database-time-zone attribute in the Moqui Conf XML file, or if not set defaults to the server's time zone (ie Java's default time zone).
Related
I want to use MomentJs to convert Firestore Timestamp (which is by Default UTC) to UTC+1. How can I do that?
firestore.Timestamp.now().toDate()
P.S. I dont want to use the local/device's time.
Firestore Timestamp (which is by Default UTC)
There is no "default" really. When you have a Timestamp object (or a JavaScript Date, or any other native date object from a modern operating system), the moment in time is always represented internally in UTC.
When you call toDate() on a timestamp, the resulting Date is still internally represented in UTC.
Don't be confused about the "default" string representation of a Date object. It will appear in the local timezone where the computer's operation system is configured. But internally, it's still UTC.
If you want to format the timestamp as a string for another timezone, you can certainly do that. momentjs has an accompanying library Moment Timezone that can help you with that. The momentjs library itself will not help you with timezones (other than the one provided by the local of the system where it is running), as it's generally understood that native timestamps are always UTC.
Date string should not be converted to local time zone. We want to show the user the date in which record is created. Due to timezone changes we have observed that date is changing.
In web we are removing the time zone so that we we are able to show the date as is.
When we get data from server we are not getting the time zone (Its GMT time). But after saving to jsonstore its getting converted to local time zone and due to that date is getting changed in some cases.
Data received from server - "2019-06-13T00:00:00-05:00"
Data received from json store - "2019-06-13T10:30:00+05:30"
Expected result - "2019-06-13T00:00:00-05:00"
JSONStore stores data as, well, JSON. JSON doesn't have a Date format while JavaScript objects do.
So, when you're writing to the JSONStore, you should convert it to a suitable format that you want - either String or time since epoch. If you convert to String, you can read it out from JSONStore as-is, but the drawback is that you cannot do arithmetic operations on the date without making another conversion.
If you store the time since epoch, you will have to convert it to the desired time zone and then display to your users.
select current_time at time zone 'GMT-2'
returns
"11:54:40.22045+02"
but correct local time in Windows is one hour different:
12:54
How to get correct local time ?
Using
"PostgreSQL 9.6.0, compiled by Visual C++ build 1800, 32-bit"
with standard postgresql.conf file in Windows 10
Same issue occurs also in ealier Postgres and in earlier windows.
Server time in Windows is correct.
Daylight saving time was changed by one hour a week ago.
Maybe postgres didnt recognized it.
Don't use time with time zone, it is a useless data type.
See the documentation:
The type time with time zone is defined by the SQL standard, but the
definition exhibits properties which lead to questionable usefulness.
In most cases, a combination of date, time, timestamp without time zone,
and timestamp with time zone should provide a complete range of date/time
functionality required by any application.
Use localtime to get the current time at your current session time zone (defined by the TimeZone parameter).
I have a TIMESTAMP field in an hsqldb table that I want to set to "2015-02-11 16:02:01.488 America/Los_Angeles", but the insert fails even if I set the column to TIMESTAMP WITH TIMEZONE, the reason being hsqldb seems to support '2008-08-08 20:08:08-8:00' format but not spelled out like America/Los_Angeles. Is there way to make the insert accept America/Los_Angeles type zones ?
Sorry, but hsqldb doesn't support working with IANA/Olson time zones directly. You are correct that TIMESTAMP WITH TIMEZONE only supports a time zone offset. You can review the hsqldb docs for confirmation.
Many databases do not support named time zone. Oracle and Postgres support them, but most others do not.
Consider also that while a named time zone can usually determine the offset, there are still cases of ambiguity around the fall-back daylight saving time transition. In other words, if you had "2015-11-01 01:30:00 America/Los_Angeles", you could not deterministically tell whether it was Pacific Daylight Time (UTC-07:00) or Pacific Standard Time (UTC-08:00). This is why usually just the offset is stored.
The converse is also true though. If you only store "-08:00" then you can't deterministically know that it came from "America/Los_Angeles".
Here's a general guideline that will help:
If the local time is unimportant, then just store a TIMESTAMP based on UTC.
If the local time is important, but the value will never be modified, then store a TIMESTAMP WITH TIMEZONE, using the local time and it's associated time zone offset.
If the local time is important AND the value can be modified, then store a TIMESTAMP WITH TIMEZONE in one column, and the time zone name (ie. "America/Los_Angeles") in a second VARCHAR column, or elsewhere in your database. During an edit operation, use the time zone name to calculate the offset of the new value. It might be the same, or it may be different.
See also DateTime vs DateTimeOffset, which presents a similar argument for .Net and/or SQL Server.
I usually have an "interceptor" that right before reading/writing from/to the database does DateTime conversion (from UTC to local time, and from local time to UTC), so I can use DateTime.Now (derivations and comparisions) throughout the system without worrying about time zones.
Regarding serialization and moving data between computers, there is no need to bother, as the datetime is always UTC.
Should I continue storing my dates (SQL 2008 - datetime) in UTC format or should I instead store it using DateTimeOffset (SQL 2008 - datetimeoffset)?
UTC Dates in the database (datetime type) have been working and known for so long, why change it? What are the advantages?
I have already looked into articles like this one, but I'm not 100% convinced though. Any thoughts?
There is one huge difference, where you cannot use UTC alone.
If you have a scenario like this
One server and several clients (all geographically in different timezones)
Clients create some data with datetime information
Clients store it all on central server
Then:
datetimeoffset stores Local time of the client and ALSO offset to the UTC time
all clients know UTC time of all data and also a local time in the place where the information originated
But:
UTC datetime stores just UTC datetime, so you do not have information about local time in the client location where data originated
Other clients do not know the local time of the place, where datetime information came from
Other clients can only calculate their local time from the database (using UTC time) not the local time of the client, where the data originated
Simple example is flight ticket reservation system ... Flight ticket should contain 2 times:
- "take off" time (in timezone of "From" city)
- "landing" time (in timezone of "Destination" city)
You are absolutely correct to use UTC for all historical times (i.e. recording events happened). It is always possible to go from UTC to local time but not always the other way about.
When to use local time? Answer this question:
If the government suddenly decide to change daylight savings, would you like this
data to change with it?
Only store local time if the answer is "yes". Obviously that will only be for future dates, and usually only for dates that affect people in some way.
Why store a time zone/offset?
Firstly, if you want to record what the offset was for the user who carried out the action, you would probably be best just doing that, i.e. at login record the location and timezone for that user.
Secondly if you want to convert for display, you need to have a table of all local time offset transitions for that timezone, simply knowing the current offset is not enough, because if you are showing a date/time from six months ago the offset will be different.
A DATETIMEOFFSET gives you the ability to store local time and UTC time in one field.
This allows for very simple and efficient reporting in local or UTC time without the need to process the data for display in any way.
These are the two most common requirements - local time for local reports and UTC time for group reports.
The local time is stored in the DATETIME portion of the DATETIMEOFFSET and the OFFSET from UTC is stored in the OFFSET portion, thus conversion is simple and, since it requires no knowledge of the timezone the data came from, can all be done at database level.
If you don't require times down to milliseconds, e.g. just to minutes or seconds, you can use DATETIMEOFFSET(0). The DATETIMEOFFSET field will then only require 8 bytes of storage - the same as a DATETIME.
Using a DATETIMEOFFSET rather than a UTC DATETIME therefore gives more flexibility, efficiency and simplicity for reporting.