Currently I am using an HTML textarea attribute to take an input from a user and then taking that text and displaying it as formatted back to the user. However, it appears to handle tabs strangely. For example, when i try to input this
Wednesday 5:00 am – 5:30 am
June 20 11:30 am – 1:30 pm
4:00 pm – 4:30 pm
6:00 am – 10:30 am
2:00 pm – 3:30 pm
Thursday 5:30 am – 10:30 am
June 21 2:30 pm – 4:30 pm
11:15 am – 1:15 pm
it comes out as this if i view to code in dev tools.
Wednesday 5:00 am – 5:30 am
June 20 11:30 am – 1:30 pm
4:00 pm – 4:30 pm
6:00 am – 10:30 am
2:00 pm – 3:30 pm
Thursday 5:30 am – 10:30 am
June 21 2:30 pm – 4:30 pm
11:15 am – 1:15 pm
I have no idea why it is doing this. How should i go about fixing this problem. Or would something other than a text area be a better solution as it is very simple. Currently this is my approach because end users wish to be able to copy and paste from word. Thanks ahead of time.
you can change the tab size property using CSS.
its default value is set to 8 char spaces and it can accept any positive integer.
foe example :
the -moz an -o are required for firefox and opera,
textarea, pre{ tab-size:6 ;
-moz-tab-size:6 ;
-o-tab-size: ;
-webkit-tab-size: 4; }
Related
I've tried get the screens order (like configured in Windows) with the Screen.screens method, but it's doesn't work... Here is the order that I get:
01, 02, 03, 10, 09, 04, 07, 08, 05, 06
But the order of the Windows is:
01, 02, 03, 04, 05, 06, 07, 08, 09, 10
Screenshot:
"Teste Monitor" is a Adobe AIR application.
How to get the correct order of the screens with as3?
I get TZ difference on windows 10 between Chrome and Edge.
When I run this code in the console:
> var date = new Date(2013, 2, 29, 1, 0, 0, 0);
> date
This will be the output when running in on Edge
> [date] Fri Mar 29 2013 01:00:00 GMT+0200 (Jerusalem Standard Time)
While This will be the output on Chrome:
> [date] Fri Mar 29 2013 01:00:00 GMT+0300 (Jerusalem Daylight Time)
It seems that in Chrome it is recognise as DST but in Edge it doesn’t, which is correct.
(Attached screenshot)
If I turn off the “Adjust for day light saving time automatically” configuration - Chrome date becomes the same. (image2)
Someone, can explain why? and how to get the correct TZ in chrome in any "Date and Time" configuration?
Edge version: 20.10240.16384.0
Chrome version: 56.0.2924.75 (64-bit)
This indeed appears to be a bug.
The TZ Database shows:
# As of 2013, DST starts at 02:00 on the Friday before the last Sunday
# in March. DST ends at 02:00 on the last Sunday of October.
# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
Rule Zion 2013 max - Mar Fri>=23 2:00 1:00 D
Rule Zion 2013 max - Oct lastSun 2:00 0 S
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone Asia/Jerusalem 2:20:54 - LMT 1880
2:20:40 - JMT 1918 # Jerusalem Mean Time?
2:00 Zion I%sT
Therefore, in 2013, DST should have started on the Friday before the last Sunday in March, which was March 29. (The previous Friday was March 22, which doesn't meet the Fri>=23 rule in the time zone data.) This is date is also corroborated by timeanddate.com.
Windows appears to have this data correct. Examining the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Israel Standard Time\Dynamic DST
The last part I highlighted in green is the DST start date.
00 00 = Year (ignored)
03 00 = Month (March)
05 00 = Day of week (Friday)
05 00 = Day number (5 = last)
02 00 = Hour (02:00)
00 00 = Minute
00 00 = Second
00 00 = Millisecond
So both the Windows and the IANA data are pointing at the same date. Yet somehow Chrome is getting it wrong.
I also tested FireFox, which also appears to be getting it wrong:
I can also reproduce these results in Node.js.
But yes, Edge is getting it correct:
Do note that the browsers also differ in which direction they adjust a local time that falls into the "gap" created by the spring-forward transition. This is expected, and is being worked on in for a future version the of ECMAScript spec.
I don't work on the actual implementation within these browsers, but my understanding is that both Chrome, Node, and FireFox rely on ICU for their time zone internals. My guess is that it is an ICU bug that is being exposed here. Update: It appears to be a bug in the Microsoft C/C++ Runtime. I'm working on getting it to the right folks.
As far as what to do about it - if accurate historical time zone data is essential to your application, I strongly suggest you not rely on the environment to provide it, but bring it yourself using one of the libraries I listed here, such as moment-timezone (which I help maintain).
I'm trying to input date strings comprising a month and year, e.g. January 2000.
According to the man page, %B (and %b) "On input, matches the name of the month in the given locale (in either abbreviated or full form, or any unique prefix of either form)", but I can't make this work:
% clock scan "January 2000" -format "%B %Y"
1475881200
% clock format 1475881200 -format "%B %Y"
October 2016
It looks to me as though Tcl doesn't understand something and is defaulting to today's date.
I'd like my command to return 946684800, the result of [clock scan 2000-01-01 -format %Y-%M-%D]
Is there a problem with [clock scan], the documentation or my reading of the documents?
I can see the same problem, but only if I don't specify the day of the month. If I do, things work:
% clock scan "1 January 2000" -format "%d %B %Y"
946684800
% clock format 946684800
Sat Jan 01 00:00:00 GMT 2000
While yes, I suppose this is a bug (and you probably ought to report it on the core.tcl-lang.org issue tracker), adding in a (fake?) day of the month seems like an easy enough workaround. After all, without it should the parser default to the current day-of-month or the first or some other day? What's the representative day? Specify it and the problem goes away.
Interesting question. It appears you need to also specify a day
$ echo 'puts [clock format [clock scan "January 2000" -format "%B %Y"]]' | tclsh8.6
Sat Oct 08 00:00:00 EDT 2016
$ echo 'puts [clock format [clock scan "1 January 2000" -format "%d %B %Y"]]' | tclsh8.6
Sat Jan 01 00:00:00 EST 2000
I see in the documentation (http://tcl.tk/man/tcl8.6/TclCmd/clock.htm) a section starting with
The date is determined according to the fields that are present in the preprocessed format string. In order of preference:
ending with
If none of the above rules results in a usable date, the date of the base time in the given time zone is used.
It's probably in #3 where you're expecting to match but aren't.
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...