Currently im storing the date of birth of a user in milliseconds (since 01.01.1970). Do i have to ensure that it is the same date of birth in every country or is it common that it can happen that it is the 11th November in country X and the 12th November in country Y?
If instead it is common practice to have the exact same date of birth in each country, how could i ensure that the milliseconds i store always point to the exact same day of month in each country?
Ignore time-of-day
Few people know the time-of-day of their birth. So, no, that level of detail is not commonly tracked. You never see time-of-birth and birth-time-zone on passports and such. They track a date-only value, without time of day and without time zone.
Bartenders, border control agents, etc. use the local current date to calculate age, with no attempt to consider time of day or adjust for time zone. Consider that partial-day difference to be truncated, ignored.
To adjust a moment accurately from one time zone to another, you need a date and a time-of-day. Without a time-of-day you have perhaps 23-25 hours of possible moments when their birth may have occurred.
For example, a birth that occurs a few minutes after midnight in Paris (1 or 2 hours ahead of UTC) on the 24th is still “yesterday” the 23rd in Montréal (4 or 5 hours behind UTC). But if that birth occurs at 06:00 in the 24th, then the date is the same (24th) in both Paris & Montreal, but is “yesterday” (23rd) in Vancouver BC and Seattle where the clocks are 7 or 8 hours behind UTC.
SQL
In SQL use a data type akin to the standard DATE type.
Java
In Java, use the LocalDate type. To represent the recurring month and day of the birthday celebration, use the MonthDay class.
For interacting with a database, drivers that comply with JDBC 4.2 should be able to work directly with LocalDate via the getObject & setObject methods on a PreparedStatement. If not, fall back to using the old java.sql.Date. New methods added to that old class facilitate conversion.
ISO 8601
When generating string representations of date-time values, use the formats defined in the ISO 8601 standard such as YYYY-MM-DD, ex: 1960-07-11. For date without year use --MM-DD, ex: --07-11. The java.time classes in Java use ISO 8601 formats by default when parsing and generating Strings.
Forcing time-of-day
If for some reason you are forced to put a date-only value into a date-time field, then you must set some arbitrary time-of-day. Noon is one possibility. I suggest setting the time portion to the first moment of the day.
First moment of the day
Be aware that the first moment is not always 00:00:00. Daylight Saving Time (DST) and perhaps other anomalies affect midnight in some time zones. So first moment of the day might be 01:00:00 for example. Java can determine the first moment of the day appropriate to a particular time zone.
ZoneId zoneId = ZoneId.of( "America/Montreal" );
LocalDate today = LocalDate.now( zoneId );
ZonedDateTime startOfToday = today.atStartOfDay( zoneId );
It is up to you to decide what time zone to interpret a selected date of birth as and what time zone to use when displaying the date of birth. In my opinion, it is logical to always use the timezone of the place of birth (if you wish to collect that) when converting the date of birth from a timestamp to readable form and when storing it. Otherwise, you can always use GMT or any other timezone as your convention. This will ensure that all users in all countries will see the same date of birth but it is recommended to append the time zone to the date representation to prevent confusion. You may of course choose to interpret dates as GMT based when creating the timestamp to store and then render the date of birth using a user-defined timezone (possibly timezone for the user's account). In this case, the date (and time if you include the time of birth) will appear different for each user.
Related
I am using momentjs to account for timezone differences in an international application. I use it to parse ISO 8601 (ex. '2021-12-17T18:40:02.389Z') strings, and expect that the date and time be local to the client. I am running into an issue where it displays both CST and CDT, for example, in the application. It seems to be using the timezone/daylight savings of the timestamp, rather than converting it to the timezone we are currently in. For example, it's December as of this posting, so I would like all times to be displayed by moment in CDT, whereas in May, I would like it to be displayed in CST, regardless of when the timestamp was created. Is this possible with moment? I haven't been able to find out about this in their docs.
I am getting date time stored as string in New York timezone (GMT -4) format from third-party website. I want to convert it to local time zone using javascript. Date time is saved in following format
"2019-04-15 19:09:16"
I know i can achieve this through MomentJS but I want to know if there is any simple solution beside loading all library to convert date time to local timezone.
On Chrome expected output could be achieved by appending GMT-4 at the end of date and
new Date("2019-04-15 19:09:16 GMT-4")
But this solution doesn't work on Firefox because of invalid format.
If you actually know that the offset is UTC-4, then you simply need to reformat your string to be compliant with the ECMAScript Date Time String Format, which is a simplification of the ISO 8601 Extended Format.
new Date("2019-04-15T19:09:16-04:00")
However, note that New York is on US Eastern Time, which is actually in daylight saving time for the date and time you provided. In other words, it isn't UTC-4 (EST), but rather UTC-5 (EDT). So for that example, it should be:
new Date("2019-04-15T19:09:16-05:00")
But what if you don't know which offset it is for a given time zone on a particular date and time? After all, time zones, daylight saving time transitions, and associated offset are different all over the world, and have changed throughout history. So one cannot just assume a time zone has a single number that is its offset. (Read more under "Time Zone != Offset" in the timezone tag wiki.)
Presently, JavaScript cannot help you with that on its own. Instead, you'll need to use a library, such as the ones referenced here.
For example, using Luxon, you can do the following:
luxon.DateTime.fromISO("2019-04-15T19:09:16", { zone: "America/New_York" }).toJSDate()
In the future, we hope to solve this in the JavaScript language via Temporal objects - which are still in the ECMAScript proposal stage.
I have a datetime string which represents a local New York time.
12/30/2020 12:00 pm
I want to parse it in javascript to get EPOCH.
The parsing has to work for users which may be in different timezones.
What I did now is
moment("07/13/2015 01:45 am -04:00", 'M/D/YYYY h:mm a Z').unix()
but this is not good because I had to hardcode
-04:00
and assume that the date I'm parsing is Eastern Daylight Saving Time.
Use the moment-timezone add-on.
moment.tz("12/30/2020 12:00 pm", "M/D/YYYY h:mm a", "America/New_York").unix()
Also, be aware that there's no guarantee that the rules for any particular time zone will persist into the future. Who knows if by 2020 if the US government won't change the DST rules again like they last did in 2007. Sure, it's not likely to affect a date in December, but in the general case you can't be certain. Especially when you consider that other time zones have changes often - about a dozen or more changes globally every year.
Oh, and one minor petpeeve... You said:
... to get EPOCH.
The word epoch means "the start of something". The Unix Epoch is 1970-01-01T00:00:00Z. It's never anything else. The value you get back from a unix timestamp is based on the epoch - but it is not itself an epoch. "Epoch Time" is a misnomer. (There are other epochs used in computing, but not with relation to Unix Time).
I have a problem with the Ext Date class seemingly returning the wrong timezone for a parsed date. Using the code below I create a date object for the 24th May, 1966 15:46 BST:
date = "1966-05-24T15:46:01+0100";
var pDate = Date.parseDate(date, "Y-m-d\\TH:i:sO", false);
I then call this:
console.log(pDate.getGMTOffset());
I am expecting to get the offset associated with the orignal date back (which is GMT + 1), but instead I get the local timezone of the browser instead. If the browser is set to a timezone far enough ahead GMT, the day portion of the date will also be rolled over (so the date will now appear as 25th May, 1966).
Does anyone know how to get around this and get Ext to recognise the correct timezone of the parsed date rather than the local browser timezone?
If this is not possible, can Ext be forced to use GMT rather than trying to interpret timezones?
I checked the parseDate() implementation in ExtJS source code and the documentation of Date in core JavaScript, the Date() constructor used by ExtJS does not support time zone information. JavaScript Date objects represent a UTC value, without the time zone. During parsing in ExtJS source code, the time zone is lost while the corresponding offset in minutes/seconds is added to the Date.
I then checked the source code of getGMTOffset() defined by ExtJS: it builds a time-zone string using the getTimezoneOffset() function defined in JavaScript.
Quoting the documentation of getTimezoneOffset():
The time-zone offset is the difference
between local time and Greenwich Mean
Time (GMT). Daylight savings time
prevents this value from being a
constant.
The time-zone is not a variable stored in the Date, it is a value that varies according to the period of the year that the Date falls in.
On my computer, with a French locale,
new Date(2010,1,20).getTimezoneOffset()
// -60
new Date(2010,9,20).getTimezoneOffset()
// -120
Edit: this behavior is not specific to Date parsing in ExtJS, the following note in the documentation of Date.parse() on Mozilla Doc Center is relevant here as well:
Note that while time zone specifiers
are used during date string parsing to
properly interpret the argument, they
do not affect the value returned,
which is always the number of
milliseconds between January 1, 1970
00:00:00 UTC and the point in time
represented by the argument.
I'm a little late but in latest ExtJS, you can pass an optional boolean to prevent the "rollover" in JS
http://docs.sencha.com/ext-js/4-0/#!/api/Ext.Date-method-parse
My two cents, because I can't really set all my time to 12:00 like Tim did. I posted on the sencha forum
What does it mean when you get or create a date in UTC format in JavaScript?
A date represents a specific point in time. This point in time will be called differently in different places. As I write this, it's 00:27 on Tuesday in Germany, 23:27 on Monday in the UK and 18:27 on Monday in New York.
To take an example method: getDay returns the day of the week in the local timezone. Right now, for a user in Germany, it would return 2. For a user in the UK or US, it would return 1. In an hour's time, it will return 2 for the user in the UK (because it will then be 00:27 on Tuesday there).
The ..UTC.. methods deal with the representation of the time in UTC (also known as GMT). In winter, this is the same timezone as the UK, in summer it's an hour behind the time in the UK.
It's summer as I write this. getUTCDay will return 1 (Monday), getUTCHours will return 22, getUTCMinutes will return 27. So it's 22:27 on Monday in the UTC timezone. Whereas the plain get... functions will return different values depending on where the user is, the getUTC.. functions will return those same values no matter where the user is.
getUTC is for converting times to Coordinated Universal Time (UTC, the acronym is ordered differently than what it stands for) which is the standard time based on the time in Greenwich, London.
The universal time is calculated using a time offset (in minutes when in JavaScript.) This offset is based on the time zone configured on the client browser's operating system.
If you plan on storing dates for users in multiple time zones, this is what you should use.
Further to Dan's remark about the acronym being different to what it stands for is a good reason: UTC Abbreviation on Wikipedia