The code is:
var rightNow = new Date();
console.log(rightNow);
In Chrome 66 it returns:
Tue Jun 12 2018 15:36:19 GMT+0530 (IST)
In Chrome 67 it returns:
Tue Jun 12 2018 15:36:43 GMT+0530 (India Standard Time)
Why the difference?
A lot of my code works with the behaviour in chrome 66. Do I need to change all the code?
In general, you should not code for a specific browser, but to the standards. In this case, the standard is ECMAScript (ECMA-262). Section 20.3.4.41 covers Date.prototype.toString(), which refers to the following section describing the internal ToDateString(tv) function, which explains:
Return an implementation-dependent String value that represents tv as a date and time in the current time zone using a convenient, human-readable form.
By "implementation-dependent", it means that the actual string value is not defined by the specification, and can vary from one implementation to another. You are not guaranteed the same result from one browser to the next, or from one version of a browser to the next, or even from one operating system to the next from the same version of the same browser.
By "human-readable form", it means that the value produced is suitable for display to a human being. It makes no guarantees about that value being represented in a manner that can be parsed consistently by computer code.
Thus, if you intend for the string value to be sent to other code, you should not use .toString(). In general, you should prefer an ISO 8601 formatted string for this purpose. Use .toISOString() if you want the result in terms of UTC. Refer to this answer (or use a library) if you want the result in terms of local time including a time zone offset.
As to why things changed between Chrome 66 and Chrome 67 - I don't have the exact details, but I assume Chrome switched from using IANA TZDB abbreviations to using CLDR time zone names, probably through its use of ICU. This is reasonable, and is what many other implementations are doing. There's no requirement it use one set of data or the other though, so don't rely on such things.
I am trying to pass a number (date in ms) to a function in a library module. The number gets screwed up!
Here is a simple look (function MailUtils.showNum has only one line, the same log call as seen below):
n = Number(todayMs - mbRetMs);
Logger.logDebug("Num = " + n + "; as Date = " + new Date(n));
MailUtils.showNum(n);
Log:
/* Num = 1500396760628; as Date = Tue Jul 18 2017 12:52:40 GMT-0400 (EDT) */
/* Num = 1453174324; as Date = Sat Jan 17 1970 14:39:34 GMT-0500 (EST) */
Seriously ???
What the * is happening? Looks like it somehow figures out it is a date and passes the origin date (the date the ms are counted from)?
LOL, Int32 Overflow #Fail. What you’re seeing is your original [64-bit] integer's 32 Least Significant Bits; the high bits have all been stripped.
Odd in itself, since JS uses Double internally; presumably a bug in JXA. (It has a lot of those.)
If you like JavaScript I strongly recommend using Node.js instead. JXA is rubbish in comparison, and with OSA technologies now in maintenance mode I don’t imagine it’ll ever get fixed.
As it is mentioned on The Google Maps Distance Matrix API - departure time is used to receive trip duration considering current traffic conditions.
I tried to get time between points in different days for example:
Fri, 02 Oct 2015 14:10:45 GMT Friday Calculation
and in the response duration is 22 min
When I set date with less traffic Sun, 04 Oct 2015 01:10:45 GMT Sunday Calculation
the response duration is again 22min.
I think the time durations should be different if in calculations are considered current traffic!
Just set departure_time=now in your query options. note now shouldn't be specified as a timestamp.
You will see a response with duration_in_traffic as a child to the elements tag or keyword
I've got some good experience with pdflib when it comes to speed of pdf-generation, even for large files. I was excpecting the same speeds from princexml as for pdflib, as both run natively on my linux server (they're not just php-classes). When generating a 1 page pdf with text and graphics, I see a 4 second time lapse between begin and loading of the document in the log file? Is this normal? The conversion itself doesn't seem to be long...
Mon Apr 16 19:17:30 2012: ---- begin
Mon Apr 16 19:17:34 2012: Loading document...
Mon Apr 16 19:17:34 2012: Converting document...
Mon Apr 16 19:17:34 2012: finished: success
Mon Apr 16 19:17:34 2012: ---- end
Are there network connections involved in your setup? Is there DNS name resolution involved? If yes, try to use IP addresses instead of hostnames and try again...
I need to convert a bunch of dates in a MySQL database from Pacific time (America/Los_Angeles) to UTC. I found a great SO answer on how to do this.
During my tests and preparation, I'm finding that I'm getting the same time conversions when using any of the following time zone names:
America/Los_Angeles
US/Pacific
PST8PDT
So my questions are the following:
Are these all just aliases to the same thing? Or are there actual differences between them at some point in time?
If I want to provide a list of timezones to users on a website, would it be better to give them selections from the America group of names, or the US group of names?
US/Pacific and PST8PDT both belong to the "other" timezones, which come with this warning:
Please do not use any of the timezones listed here (besides UTC), they only exist for backward compatible reasons.
They should all refer to the same timezone, compare:
http://www.travelmath.com/time-zone/PST8PDT
http://www.travelmath.com/time-zone/US/Pacific
http://www.travelmath.com/time-zone/America/Los_Angeles
As such, you should use America/Los_Angeles, which incidentally should also be a pretty "natural" and easy thing to select for users.
I ran into an issue with the parallel US/Eastern, Americas/New_York, and EST5EDT. Here is what I discovered.
For dates after the Uniform Time Act of 1966 went into effect in 1967, these timezones are all identical. Also the US enforced standard DST rules during the World Wars, so they are all identical 1918-1919 and 1942-1945.
For any date before 1918, between 1920 and 1941 inclusive, and between 1946 and 1966 inclusive, EST5EDT will always be identical to EST. PST8PDT will always be identical to PST.
Prior to 1967, Americas/New_York will provide the time as observed in New York City. So Daylight Savings Time will follow the rules in place by the NYC municipal or NY state government. Any date before 1883 Nov 18 12:03:58 will be in local mean time with an offset of -4:56:02 from UTC. For Americas/Los_Angeles any time before 1883 Nov 18 12:07:02 will be local mean time with an offset of -7:52:58 from UTC. Between 1883 and 1967, Los Angeles follows the LA and California Daylight Savings rules.
Here is a fragment of Ruby showing the difference:
# In PST8PDT 1966 has no DST, but 1967 does.
ENV['TZ']='PST8PDT'
[Time.mktime(1966,6,2),Time.mktime(1967, 6, 2)]
=> [1966-06-02 00:00:00 -0800, 1967-06-02 00:00:00 -0700]
# In America/Los_Angeles both dates are in DST.
ENV['TZ']='America/Los_Angeles'
[Time.mktime(1966,6,2),Time.mktime(1967, 6, 2)]
=> [1966-06-02 00:00:00 -0700, 1967-06-02 00:00:00 -0700]
If you install the tzinfo gem for ruby you can see the difference between PST8PDT and Americas/Los_Angeles for historic dates:
require 'tzinfo'
# Here an old date will use modern timezone rules.
Time.new(1867, 6, 2, 0, 0, 0, TZInfo::Timezone.get("PST8PDT"))
=> 1867-06-02 00:00:00 -0800
# Here an old date predates timezones, so local time is used.
Time.new(1867, 6, 2, 0, 0, 0, TZInfo::Timezone.get("America/Los_Angeles"))
=> 1867-06-02 00:00:00 -0752
Odd things can happen if you have multiple systems where one assumes PST8PDT and the other assumes Americas/Los_Angeles, especially when a system is storing DATE fields as DATETIME fields with the hours/minutes/seconds set to midnight. Data might look fine for anything recent. But a birthdate for example, from the summer of 1966 might get moved an hour, then truncated so it appears to be on the prior day.
And just for extra fun if you are dealing with old dates in Alaska, you need to remember that Alaska was Purchased from Russia. Dates before 1867 Oct 18 are on the other side of the international date line and use the Julian, not Gregorian Calendar. So Juneau, for example, went from 6 Oct 1867 (Julian) +15:02:19 to 18-Oct-1867 (Gregorian) -8:57:41. (The TZInfo library doesn't handle the Gregorian to Julian change.)
Time.new(1867, 10, 18, 0, 0, 0, TZInfo::Timezone.get("America/Juneau"))
=> 1867-10-18 00:00:00 +1502
Time.new(1867, 10, 19, 0, 0, 0, TZInfo::Timezone.get("America/Juneau"))
#error message
TZInfo::AmbiguousTime (1867-10-19 00:00:00 is an ambiguous local time.)
Time.new(1867, 10, 20, 0, 0, 0, TZInfo::Timezone.get("America/Juneau"))
=> 1867-10-20 00:00:00 -0857
Time.new(1867, 10, 18, 0, 0, 0, TZInfo::Timezone.get("America/Juneau")).to_datetime.julian
=> 1867-10-06 00:00:00 +1502
US/Pacific is a "link" to America/Los_Angeles in the IANA database (see wikipedia). On Linux systems I've seen, the former is a hard linked file to the latter; on OS X it might be a copy. If you run a checksum (e.g. md5 or sha1) on the entries in /usr/share/zoneinfo/ the 2 should match.
However, PST8PDT may be different - I haven't figured out exactly how. This bug report indicates that it doesn't track the history of daylight-saving changes, i.e. that it just retroactively applies the current DST rules to the past; but that doesn't seem to be the case in this ruby example. If it were retroactively applying the current rules, both would be -0700:
> ENV['TZ']='PST8PDT'
> [Time.mktime(2006, 4, 2, 1, 59, 59), Time.mktime(2006, 4, 2, 2)]
=> [2006-04-02 01:59:59 -0800, 2006-04-02 03:00:00 -0700]
On this message there's a quote from the original database maintainer. The message author explains that the legacy zones including PST8PDT used to have obsolete info, but now are "less incorrect" whatever that means.
To sum up, don't use PST8PDT, but it should be safe to use either US/Pacific or America/Los_Angeles.